perm filename LISP.BUG[BUG,LSP] blob
sn#861896 filedate 1988-10-08 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00222 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00031 00002 BUG-LISP and LISP-FORUM
C00032 00003 ∂20-Aug-82 2041 George J. Carrette <GJC at MIT-MC> fixes to maclisp
C00033 00004 ∂21-Aug-82 1157 John Ruttenberg <Ruttenberg at YALE> Bug in setf and arraycall
C00036 00005 ∂21-Aug-82 1207 Jonathan Rees <Rees at YALE> (SSTATUS SYNTAX #/| ...)
C00037 00006 ∂22-Aug-82 1558 Alan Bawden <ALAN at MIT-MC> (SSTATUS SYNTAX #/| ...)
C00039 00007 ∂22-Aug-82 1647 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
C00041 00008 ∂22-Aug-82 1923 John Ruttenberg <Ruttenberg at YALE> Re: push/defvst interaction?
C00043 00009 ∂23-Aug-82 0001 George J. Carrette <GJC at MIT-MC> push/defvst interaction?
C00046 00010 ∂23-Aug-82 1409 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
C00049 00011 ∂24-Aug-82 1545 Glenn S. Burke <GSB at MIT-ML> distribution request
C00050 00012 ∂24-Aug-82 1939 Greg Skinner <EE.GDS at MIT-OZ> Lisp problem
C00052 00013 ∂24-Aug-82 1939 Barry Margolin at MIT-MULTICS Re: Lisp problem
C00054 00014 ∂27-Aug-82 1306 Glenn S. Burke <GSB at MIT-ML> (SSTATUS SYNTAX #/| ...)
C00056 00015 ∂29-Aug-82 2313 GSB@MIT-ML new format installed on MC and OZ
C00057 00016 ∂30-Aug-82 1613 JonL at PARC-MAXC Re: fixes to maclisp
C00059 00017 ∂30-Aug-82 2236 Kent M. Pitman <KMP at MIT-MC> FORMAT losing
C00061 00018 ∂31-Aug-82 2102 Glenn S. Burke <GSB at MIT-MC>
C00062 00019 ∂31-Aug-82 2107 Glenn S. Burke <GSB at MIT-MC>
C00063 00020 ∂31-Aug-82 2310 George J. Carrette <GJC at MIT-MC> hacking/assembly maclisp
C00065 00021 ∂01-Sep-82 1043 Robert P. Krajewski <RpK at MIT-ML> WITH-OPEN-FILE
C00067 00022 ∂01-Sep-82 1333 Kent M. Pitman <KMP at MIT-MC> WITH-OPEN-FILE
C00068 00023 ∂01-Sep-82 1403 Alan Bawden <ALAN at MIT-MC> WITH-OPEN-FILE
C00071 00024 ∂01-Sep-82 1958 Glenn S. Burke <GSB at MIT-MC> renamef failure
C00072 00025 ∂01-Sep-82 2045 FEINBERG at CMU-20C renamef failure
C00073 00026 ∂01-Sep-82 2227 Kent M. Pitman <KMP at MIT-MC>
C00074 00027 ∂06-Sep-82 1540 Devon S. McCullough <Devon at MIT-ML>
C00076 00028 ∂06-Sep-82 1544 Kent M. Pitman <KMP at MIT-MC>
C00077 00029 ∂06-Sep-82 1827 Robert Elton Maas <REM at MIT-MC> (LISTEN)
C00078 00030 ∂07-Sep-82 1329 Glenn S. Burke <GSB at MIT-ML> (LISTEN)
C00079 00031 ∂07-Sep-82 1737 Glenn S. Burke <GSB at MIT-MC> suspend tty code fix (tops-20 vts)
C00081 00032 ∂07-Sep-82 1738 Skef Wholey <Wholey at CMU-20C> Complr's losing lossage, of course
C00083 00033 ∂07-Sep-82 2221 Glenn S. Burke <GSB at MIT-MC> load-byte/deposit-byte miscompilation
C00084 00034 ∂09-Sep-82 0021 GSB@MIT-ML previous patch, to OPNT2
C00085 00035 ∂13-Sep-82 1324 Kent M. Pitman <KMP at MIT-MC>
C00087 00036 ∂14-Sep-82 1102 Jonathan Alan Solomon <JSol at USC-ECLC>
C00089 00037 ∂14-Sep-82 2252 Stavros M. Macrakis <MACRAK at MIT-MC> < WNA msg
C00090 00038 ∂17-Sep-82 1643 Glenn S. Burke <GSB at MIT-ML> (status ttysize) on 20X
C00091 00039 ∂17-Sep-82 1658 GSB@MIT-ML (status ttysize) bug, 20x
C00092 00040 ∂17-Sep-82 1701 GSB@MIT-ML previous patch
C00094 00041 ∂01-Oct-82 0404 Kent M. Pitman <KMP at MIT-MC> More data
C00096 00042 ∂02-Oct-82 1234 Alan Bawden <ALAN at MIT-MC> ALPHALESSP: More data
C00098 00043 ∂29-Oct-82 1519 Alan Bawden <ALAN at MIT-MC> [TONYH: forwarded] (bug-PROGRAM??????)
C00102 00044 ∂29-Oct-82 1702 JONL at PARC-MAXC Your recent note on MacLisp errors
C00115 00045 ∂31-Oct-82 1132 TONYH at MIT-AI
C00120 00046 ∂31-Oct-82 1308 George J. Carrette <GJC at MIT-MC> lossage after lossage
C00123 00047 ∂01-Nov-82 1417 David Eppstein <CSD.Kronj at SU-SCORE> SUBFORK module (LEDIT)
C00128 00048 ∂03-Nov-82 2158 JONL at PARC-MAXC 4th level indirection -- maybe you haven't yet seen this?
C00131 00049 ∂20-Nov-82 1508 GJC at MIT-MC FLAME warning: Scheme broken on OZ today.
C00135 00050 ∂20-Nov-82 1932 David C. Plummer <DCP at MIT-MC> Re: Scheme broken on OZ today.
C00143 00051 ∂21-Nov-82 2357 Martin David Connor <MARTY at MIT-MC> A minor update for Top-20 Maclisp
C00159 00052 ∂19-Dec-82 1947 JONL at PARC-MAXC Re: (\ x 0) revisited, revisited, revisited
C00161 00053 ∂19-Dec-82 2023 Glenn S. Burke <GSB at MIT-ML> Re: Re: (\ x 0) revisited, revisited, revisited
C00165 00054 ∂26-Dec-82 1917 PB e-subjob communication
C00167 00055 ∂08-Jan-83 1147 EB @ MIT-MC
C00168 00056 ∂11-Jan-83 1506 EB @ MIT-MC
C00169 00057 ∂21-Jan-83 1441 JOSHM at MIT-OZ How do I...
C00170 00058 ∂21-Jan-83 1448 JOSHM at MIT-OZ at MIT-MC How do I...
C00171 00059 ∂21-Jan-83 1850 Feinberg@CMU-CS-C How do I...
C00175 00060 ∂14-Feb-83 2041 Communications Satellite <COMSAT @ MIT-MC> Msg of Monday, 14 February 1983 20:12 EST
C00177 00061 ∂05-Apr-83 1711 Alan Bawden <ALAN @ MIT-MC> buglisphack@sail
C00178 00062 ∂05-Apr-83 1911 George J. Carrette <GJC @ MIT-MC> LOOP macro expansions into LET
C00180 00063 ∂05-Apr-83 2251 David C. Plummer <DCP@SCRC-TENEX> LOOP macro expansions
C00182 00064 ∂07-Apr-83 0125 Alan Bawden <ALAN @ MIT-MC>
C00183 00065 ∂07-Apr-83 0234 Alan Bawden <ALAN@MIT-OZ> I though we fixed this?
C00185 00066 ∂08-Apr-83 2325 Alan Bawden <ALAN @ MIT-MC> Gratuitous optimization
C00186 00067 ∂11-Apr-83 2051 Kent M. Pitman <KMP @ MIT-MC>
C00188 00068 ∂11-Apr-83 2052 Kent M. Pitman <KMP @ MIT-MC>
C00189 00069 ∂11-Apr-83 2323 Pandora B. Berman <CENT @ MIT-ML> file migrated
C00191 00070 ∂13-Apr-83 2209 Dave Touretzky at CMU-CS-A CMU MacLisp broken
C00193 00071 ∂17-Apr-83 1349 PASIEKA@MIT-OZ Pretty-Printer
C00197 00072 ∂18-Apr-83 2004 WILLIS@MIT-ML
C00199 00073 ∂18-Apr-83 2117 Kent M. Pitman <kmp at MIT-MC> WILLIS@ML's TYO gripe
C00200 00074 ∂18-Apr-83 2129 Alan Bawden <ALAN @ MIT-MC> IMAGE mode IO
C00215 00075 ∂11-May-83 0928 @USC-ECL,@MIT-MC:SMATT@MIT-OZ LOOP CONTINUE STATEMENT
C00217 00076 ∂11-May-83 0931 @USC-ECL,@MIT-MC:MOON@SCRC-TENEX LOOP CONTINUE STATEMENT
C00220 00077 ∂11-May-83 1022 @USC-ECL,@MIT-MC:SMATT@MIT-OZ LOOP CONTINUE STATEMENT
C00222 00078 ∂14-May-83 1416 @USC-ECL,@MIT-MC:KMP@MIT-OZ <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
C00226 00079 ∂14-May-83 1632 @USC-ECL:KMP@MIT-MC
C00228 00080 ∂15-May-83 0920 @USC-ECL,@MIT-MC:GJC@MIT-MC <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
C00231 00081 ∂26-May-83 2214 @USC-ECL,@MIT-MC:ALAN@MIT-OZ Yuch!
C00233 00082 ∂04-Jun-83 1636 @USC-ECL,@MIT-MC:SAZ@MIT-OZ binding 't to other things (like nil)
C00234 00083 ∂14-Jun-83 0306 @USC-ECL,@MIT-MC:CENT@MIT-ML files migrated on oz
C00237 00084 ∂14-Jun-83 2302 @USC-ECL,@MIT-MC:VaughanW@HI-MULTICS Call For Papers
C00242 00085 ∂16-Jun-83 1714 @USC-ECL:ALAN@MIT-MC New MacLisp now installed on MC.
C00255 00086 ∂29-Jun-83 1119 @USC-ECL:CFFK@MIT-MC Cursor positioning with Tops-20 lisp (in Macsyma on XX)
C00260 00087 ∂04-Jul-83 1523 @USC-ECL:JGA@MIT-MC a question of interrupts (I guess)
C00268 00088 ∂15-Jul-83 1751 @USC-ECL:ALAN@MIT-MC Mustn't call UINT0 from within a PI server
C00273 00089 ∂15-Jul-83 1927 @USC-ECL,@MIT-MC:GSB@MIT-ML .lose because of intpdl
C00274 00090 ∂16-Jul-83 2233 @USC-ECL:JPG@MIT-MC
C00278 00091 ∂19-Jul-83 1917 @USC-ECL,@MIT-MC:BEN@MIT-ML Bug in DO when compiled.
C00280 00092 ∂19-Jul-83 1917 @USC-ECL:KMP@MIT-MC
C00284 00093 ∂20-Jul-83 2228 @USC-ECL:ALAN@MIT-MC More bits.
C00296 00094 ∂05-Aug-83 1143 @USC-ECL,@MIT-MC:JUDY@MIT-OZ problem with setting the status of the random function
C00300 00095 ∂05-Aug-83 1224 @USC-ECL:KMP@MIT-MC Judy's RANDOM bug
C00302 00096 ∂06-Aug-83 0133 @USC-ECL:ALAN@MIT-MC (sstatus random (status random))
C00305 00097 ∂23-Aug-83 1147 @USC-ECL,@MIT-MC:PADGET@UTAH-20 function cells
C00312 00098 ∂23-Aug-83 1424 @USC-ECL,@MIT-MC:Deutsch.PA@PARC-MAXC Re: function cells
C00320 00099 ∂30-Aug-83 1738 @USC-ECL,@MIT-MC:Bobrow.PA@PARC-MAXC Re: function cells
C00322 00100 ∂30-Aug-83 2109 @USC-ECL:GJC@MIT-MC Function cells.
C00325 00101 ∂01-Sep-83 0534 @USC-ECL,@MIT-MC:TIM@MIT-OZ Function cells
C00329 00102 ∂01-Sep-83 1454 @USC-ECL,@MIT-MC:Bobrow.PA@PARC-MAXC Re: Function cells
C00332 00103 ∂01-Sep-83 1549 @USC-ECL,@MIT-MC:BENSON@SPA-NIMBUS Re: Function cells
C00336 00104 ∂01-Sep-83 1632 @USC-ECL,@MIT-MC:Deutsch.PA@PARC-MAXC Re: Function cells
C00339 00105 ∂01-Sep-83 1707 @USC-ECL,@MIT-MC:PADGET@UTAH-20 Re: Function cells
C00344 00106 ∂01-Sep-83 1817 @USC-ECL,@MIT-MC:Bobrow.PA@PARC-MAXC Re: Function cells
C00346 00107 ∂03-Sep-83 1232 @USC-ECL,@MIT-MC:ZVONA@MIT-OZ Function cells
C00354 00108 ∂03-Sep-83 1833 @USC-ECL,@MIT-MC:RWK@SCRC-TENEX Function cells
C00368 00109 ∂05-Sep-83 1235 @USC-ECL,@MIT-MC:Moon@SCRC-TENEX Function cells
C00370 00110 ∂05-Sep-83 1325 @USC-ECL,@MIT-MC:jkf%ucbkim@Berkeley Re: Function cells
C00373 00111 ∂05-Sep-83 1347 @USC-ECL,@MIT-MC:ZVONA@MIT-OZ Function cells
C00386 00112 ∂05-Sep-83 1625 @USC-ECL:GJC@MIT-MC Zippy the mailer, or ... are we on the net yet?
C00398 00113 ∂06-Sep-83 1759 @USC-ECL,@MIT-MC:PADGET@UTAH-20 Re: Function cells
C00403 00114 ∂06-Sep-83 1814 @USC-ECL:KMP@MIT-MC
C00405 00115 ∂06-Sep-83 1814 @USC-ECL:DCP@MIT-MC
C00407 00116 ∂17-Sep-83 1709 @USC-ECL:RIVIN@MIT-MC
C00408 00117 ∂17-Sep-83 1859 @USC-ECL,@MIT-MC:GLR@MIT-OZ SETSYNTAX and (STATUS CHTRAN) on TOPS-20
C00412 00118 ∂21-Sep-83 2258 @USC-ECL,@MIT-MC:kmp@MIT-MC TYIPEEK and SFAs -- A longstanding bug that needs fixing
C00419 00119 ∂27-Sep-83 1631 @USC-ECL,@MIT-MC:JonL.pa@PARC-MAXC Function Cells -- the history
C00431 00120 ∂27-Sep-83 1716 @USC-ECL:GJC@MIT-MC your note on Function Cells.
C00436 00121 ∂30-Sep-83 1202 @USC-ECL,@MIT-MC:GLR@MIT-OZ
C00444 00122 ∂08-Nov-83 1944 @USC-ECL,@MIT-MC:Alan@MIT-MC
C00459 00123 ∂15-Nov-83 0035 @USC-ECL,@MIT-MC:Gumby@MIT-MC correction: ledit hook
C00461 00124 ∂16-Nov-83 0120 @USC-ECL:JPG@MIT-MC (TYO #\BS) in Tops20 Maclisp
C00463 00125 ∂16-Nov-83 1138 @USC-ECL:GJC@MIT-MC (TYO #\BS) in Tops20 Maclisp
C00466 00126 ∂29-Nov-83 0022 @USC-ECL:KMP@MIT-MC
C00471 00127 ∂11-Dec-83 1737 @USC-ECL:KMP@MIT-MC SASW: use of ALLFILES
C00472 00128 ∂15-Dec-83 2149 YM (on TTY1) BCOMPLR deleted files
C00474 00129 ∂19-Dec-83 1429 @USC-ECL,@MIT-MC:YM@SU-AI BCOMPLR deleted files
C00476 00130 ∂03-Jan-84 1825 CJL%MIT-OZ%MIT-MC.ARPA@USC-ECL.ARPA Setf's of load-byte don't work - broken foo-byte-expander
C00478 00131 ∂04-Jan-84 0848 JONL.PA%PARC-MAXC.ARPA@USC-ECL.ARPA Re: Setf's of load-byte don't work - broken foo-byte-expander
C00480 00132 ∂04-Jan-84 0849 JONL.PA%PARC-MAXC.ARPA@USC-ECL.ARPA Re: Setf's of load-byte don't work - broken foo-byte-expander
C00482 00133 ∂04-Jan-84 0849 ALAN%MIT-MC.ARPA@USC-ECL.ARPA Re: Setf's of load-byte don't work - broken foo-byte-expander
C00485 00134 ∂09-Jan-84 1137 @USC-ECL,@MIT-MC:MARTY%MIT-OZ@MIT-MC LOAD and pathnames
C00488 00135 ∂24-Jan-84 1547 @USC-ECL:ALAN@MIT-MC The comment is not mine
C00490 00136 ∂24-Jan-84 1751 @USC-ECL:DEVON@MIT-MC The comment is not mine
C00493 00137 ∂24-Jan-84 1850 @USC-ECL,@MIT-MC:PGS@MIT-OZ yech
C00495 00138 ∂31-Jan-84 1359 @USC-ECL,@MIT-MC:CJL@MIT-OZ (STATUS TTYSIZE) is broken for lengths and widths > 127. on TWENEX
C00500 00139 ∂06-Feb-84 0906 DEVON%MIT-MC.ARPA@USC-ECL.ARPA is it or isn't it a COMPLR bug?
C00505 00140 ∂06-Feb-84 0935 ALAN%MIT-MC.ARPA@USC-ECL.ARPA is it or isn't it a COMPLR bug?
C00508 00141 ∂08-Feb-84 0141 @USC-ECL.ARPA,@MIT-MC:JonL.pa@PARC-MAXC DO: an interpreter bug
C00510 00142 ∂08-Feb-84 1350 @USC-ECL.ARPA:WGD@MIT-MC DO: an interpreter bug
C00513 00143 ∂08-Feb-84 1429 @USC-ECL.ARPA:ALAN@MIT-MC DO: an interpreter bug
C00515 00144 ∂10-Feb-84 1041 @USC-ECL.ARPA:ALAN@MIT-MC MSGFILES, Heralds
C00518 00145 ∂10-Feb-84 1916 @USC-ECL.ARPA:KMP@MIT-MC MSGFILES, Heralds
C00521 00146 ∂15-Feb-84 0639 @USC-ECL.ARPA,@MIT-MC:SAE-ADA@USC-ECLB Addition to list
C00523 00147 ∂21-Feb-84 1928 @USC-ECL.ARPA,@MIT-MC:LAMPING@SU-SCORE Control Character I/O
C00525 00148 ∂21-Feb-84 2054 @USC-ECL.ARPA,@MIT-MC,@CMU-CS-C:ZUBKOFF%TARTAN@CMU-CS-C Control Character I/O
C00527 00149 ∂22-Feb-84 0926 @USC-ECL.ARPA:KMP@MIT-MC Opening files locally
C00532 00150 ∂25-Feb-84 1424 @USC-ECL.ARPA,@MIT-MC:CS204.CASLEY@SU-SCORE Re: A Bug in Maclisp -- emacs?
C00535 00151 ∂02-Mar-84 2104 @USC-ECL.ARPA,@MIT-MC:G.DAIR@SU-SCORE MACLISP availablity
C00543 00152 ∂11-Mar-84 1217 @USC-ECL.ARPA,@MIT-MC:MASINTER.PA@PARC-MAXC Backquote history
C00544 00153 ∂11-Mar-84 1240 @USC-ECL.ARPA:ALAN@MIT-MC Backquote history
C00546 00154 ∂11-Mar-84 1316 @USC-ECL.ARPA:KMP@MIT-MC Backquote history
C00555 00155 ∂12-Mar-84 0912 @USC-ECL.ARPA,@MIT-MC:acw@SCC-WAIKATO Backquote history
C00558 00156 ∂12-Mar-84 1043 @USC-ECL.ARPA:KMP@MIT-MC [GJS: Backquote history]
C00562 00157 ∂12-Mar-84 1237 @USC-ECL.ARPA:ALAN@MIT-MC Backquote history
C00564 00158 ∂12-Mar-84 1311 @USC-ECL.ARPA,@MIT-MC:masinter.pa@PARC-MAXC Re: Backquote history
C00567 00159 ∂12-Mar-84 1447 @USC-ECL.ARPA,@MIT-MC:Mcdermott@YALE Backquote
C00570 00160 ∂12-Mar-84 2027 @USC-ECL.ARPA,@MIT-MC:JONL.PA@PARC-MAXC History of "backquote" macro
C00574 00161 ∂24-Mar-84 1304 @USC-ECL.ARPA,@MIT-MC:ROBOT.GML@MIT-OZ
C00576 00162 ∂24-Mar-84 1526 @USC-ECL.ARPA:ALAN@MIT-MC NCONC vs. APPEND
C00579 00163 ∂28-Mar-84 0930 @USC-ECL.ARPA:JGA@MIT-MC Mac-Lisp
C00580 00164 ∂29-Mar-84 0932 @USC-ECL.ARPA:GUMBY@MIT-MC Mac-Lisp
C00582 00165 ∂04-Apr-84 1045 @USC-ECL.ARPA:JGA@MIT-MC How intelligent is the complr?
C00584 00166 ∂04-Apr-84 1158 @USC-ECL.ARPA:ALAN@MIT-MC How intelligent is the complr?
C00585 00167 ∂04-Apr-84 1227 @USC-ECL.ARPA,@MIT-MC:JONL.PA@PARC-MAXC Re: How intelligent is the complr?
C00587 00168 ∂05-Apr-84 1531 @USC-ECL.ARPA:ALAN@MIT-MC How intelligent is the complr?
C00589 00169 ∂05-Apr-84 1620 @USC-ECL.ARPA,@MIT-MC:JONL.PA@PARC-MAXC Re: How intelligent is the complr?
C00591 00170 ∂05-Apr-84 2232 @USC-ECL.ARPA,@MIT-MC:RWK@SCRC-YUKON How intelligent is the complr?
C00594 00171 ∂13-Apr-84 1142 REM (on TTY25) Bug in SPRIN1 here
C00595 00172 ∂29-Apr-84 2140 @USC-ECL.ARPA,@MIT-MC:cfry@MIT-OZ eval-while-possible
C00598 00173 ∂30-Apr-84 1439 @USC-ECL.ARPA:GZ@MIT-MC DEFSTRUCT predicate option
C00599 00174 ∂02-Jun-84 1057 @USC-ECL.ARPA:BMT@MIT-MC
C00600 00175 ∂03-Jun-84 2126 @USC-ECL.ARPA:ALAN@MIT-MC Hunks
C00604 00176 ∂04-Jun-84 1153 @USC-ECL.ARPA,@MIT-MC:REM@SU-AI Unnamed arrays not GC'd like they should.
C00608 00177 ∂12-Jun-84 1855 @USC-ECL.ARPA:GSB@MIT-MC Unnamed arrays not GC'd like they should.
C00610 00178 ∂16-Jun-84 1614 @USC-ECL.ARPA:ALAN@MIT-MC help in setting up LISP on PREP
C00613 00179 ∂16-Jun-84 1614 @USC-ECL.ARPA,@MIT-MC:DRogers@MIT-OZ help in setting up LISP on PREP
C00615 00180 ∂28-Jul-84 1230 @USC-ECL.ARPA:ALAN@MIT-MC
C00617 00181 ∂11-Sep-84 1228 @USC-ECL.ARPA,@MIT-MC:JonL.pa@Xerox [MJackson.Wbst: Why Your Pascal and Modula-2 Programs Don't
C00619 00182 ∂13-Sep-84 2030 @USC-ECL.ARPA,@MIT-MC:BERWICK.PILATO@MIT-OZ
C00624 00183 ∂24-Sep-84 1419 @USC-ECL.ARPA:KMP@MIT-MC m-F in LEDIT
C00626 00184 ∂24-Sep-84 1431 @USC-ECL.ARPA,@MIT-MC:EB@MIT-OZ cursorpos broken on batch jobs
C00627 00185 ∂28-Sep-84 1437 @USC-ECL.ARPA,@MIT-MC:EB@MIT-OZ ferror
C00628 00186 ∂07-Oct-84 1408 @USC-ECL.ARPA:GZ@MIT-MC GETCOR
C00629 00187 ∂08-Oct-84 1113 @USC-ECL.ARPA,@MIT-MC:cpd@UCLA-LOCUS Benchmark - PERQ CL vs Apollo T
C00635 00188 ∂08-Oct-84 1301 @USC-ECL.ARPA,@MIT-MC:WHOLEY@CMU-CS-C Benchmark - PERQ CL vs Apollo T
C00640 00189 ∂10-Oct-84 0156 @USC-ECL.ARPA:GZ@MIT-MC ||
C00641 00190 ∂10-Oct-84 0919 @USC-ECL.ARPA,@MIT-MC:jrg@cmu-cs-spice UCLA Perq
C00644 00191 ∂10-Oct-84 1005 @USC-ECL.ARPA:ALAN@MIT-MC ||
C00646 00192 ∂10-Oct-84 1626 @USC-ECL.ARPA:KMP@MIT-MC
C00648 00193 ∂10-Oct-84 2038 @USC-ECL.ARPA:ALAN@MIT-MC ↑@
C00651 00194 ∂05-Dec-84 0859 @USC-ECL.ARPA,@MIT-MC:RLB@SCRC-TENEX GC
C00654 00195 ∂06-Dec-84 1057 @USC-ECL.ARPA:ALAN@MIT-MC GC
C00662 00196 ∂10-Jan-85 1525 @USC-ECL.ARPA:MACRAK@MIT-MC MACRAK's SUBLIS problems
C00672 00197 ∂06-Feb-85 1133 @MIT-MC:EB@MIT-OZ the infamous NNNNN NOT ASCII VALUE
C00673 00198 ∂22-Feb-85 0235 @MIT-MC:MDC.WAYNE@MIT-OZ Array Bug
C00674 00199 ∂22-Feb-85 1217 ALAN@MIT-MC Array Bug
C00677 00200 ∂20-Mar-85 1532 @MIT-MC:Margolin.Multics@MIT-MULTICS.ARPA defsubst in Maclisp
C00679 00201 ∂20-Mar-85 2038 @MIT-MC:KMP@SCRC-STONY-BROOK defsubst in Maclisp
C00686 00202 ∂24-Mar-85 1315 ALAN@MIT-MC mapcan and get
C00693 00203 ∂05-May-85 1648 @MIT-MC:KMP@SCRC-STONY-BROOK.ARPA MDC.WAYNE: "list" command
C00695 00204 ∂07-May-85 1353 @MIT-MC:PWEYHRAUCH@SUMEX-AIM.ARPA EXEC/MACLISP interface problem
C00697 00205 ∂07-May-85 1404 @MIT-MC:PWEYHRAUCH@SUMEX-AIM.ARPA EXEC/MACLISP interface problem
C00699 00206 ∂07-May-85 1411 @MIT-MC:KMP@SCRC-STONY-BROOK.ARPA EXEC/MACLISP interface problem
C00702 00207 ∂07-May-85 1440 @MIT-MC:KMP@SCRC-STONY-BROOK.ARPA [Daniel S. Blom: Re: EXEC/MACLISP interface problem]
C00705 00208 ∂07-May-85 1451 GJC@MIT-MC EXEC/MACLISP interface problem
C00707 00209 ∂07-May-85 1503 @MIT-MC:KMP@SCRC-STONY-BROOK.ARPA EXEC/MACLISP interface problem
C00728 00210 ∂10-May-85 1752 host MIT-MC.ARPA EXEC/MACLISP interface problem
C00730 00211 ∂19-May-85 0117 @MIT-MC:MKL@SRI-CSL distribution copies
C00732 00212 ∂19-May-85 0236 @MIT-MC:GUMBY@MIT-MC distribution copies
C00734 00213 ∂19-May-85 1240 @MIT-MC:FREEMAN@SUMEX-AIM Re: distribution copies
C00739 00214 ∂06-Jun-85 2159 @MIT-MC.ARPA:sjk@SRI-AI.ARPA Re: distribution copies
C00742 00215 ∂11-Jun-85 0553 MACRAK@MIT-MC.ARPA Timit
C00743 00216 ∂11-Jun-85 0927 @MIT-MC.ARPA:KMP@SCRC-STONY-BROOK.ARPA Timit
C00745 00217 ∂24-Jun-85 1754 @MIT-MC.ARPA:Hornig@SCRC-STONY-BROOK.ARPA Common Lisp defsetf
C00750 00218 ∂16-Sep-85 1547 @MIT-MC.ARPA:J.Dalton%edxa@UCL-CS.ARPA Scheme availability
C00754 00219 ∂06-Nov-85 1418 @MIT-MC.ARPA:Soley@MIT-MC.ARPA Common Lisp meeting
C00757 00220 ∂16-Jan-86 1847 @MC.LCS.MIT.EDU:carr%utah-orion@utah-cs.arpa (TRACE q1 q2 ... ) patterns
C00759 00221 ∂05-Feb-86 1456 JAR@MC.LCS.MIT.EDU ALLFILES behavior
C00760 00222 ∂10-Apr-86 1704 @MC.LCS.MIT.EDU:KMP@SCRC-STONY-BROOK.ARPA Use of LISP-FORUM
C00763 ENDMK
C⊗;
BUG-LISP and LISP-FORUM
∂20-Aug-82 2041 George J. Carrette <GJC at MIT-MC> fixes to maclisp
Date: 20 August 1982 23:27-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: fixes to maclisp
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC
Can you tell us the best way to assemble a Maclisp on a tops-20
so that we can put in the various accumulated fixes in the version
on OZ? For example, the MT fix to suspend. Thanks.
∂21-Aug-82 1157 John Ruttenberg <Ruttenberg at YALE> Bug in setf and arraycall
Date: 14-Aug-82 10:55AM-EDT (Sat)
From: John Ruttenberg <Ruttenberg at YALE>
Subject: Bug in setf and arraycall
To: Bug-Lisp at MIT-MC
Seems to be a problem with push and arraycall. Here's the source file:
(defvst bug-st
(a = (*array () t 10))
)
(defmacro bug-st-ai (self index)
`(arraycall t (bug-st-a ,self) ,index))
(defun bug (self member index)
(push member (bug-st-ai self index)))
(setq b (cons-a-bug-st))
(bug b 'a 4)
(bug b 'a 4)
And here's how Maclisp takes it:
Yale Haclisp 82 (in Maclisp 2088)
> (defvst bug-st
(a = (*array () t 10))
)
;Loading DEFVST 3
;Loading EXTMAC 183
;Loading ERRCK 20
;Loading VECTOR 64
;Loading DEFVSX 85
BUG-ST
>(defmacro bug-st-ai (self index)
`(arraycall t (bug-st-a ,self) ,index))
BUG-ST-AI
>(defun bug (self member index)
(push member (bug-st-ai self index)))
BUG
>(setq b (cons-a-bug-st))
#{BUG-ST A #T-10-71712}
>(bug b 'a 4)
(A)
>(bug b 'a 4)
;G0017 UNBOUND VARIABLE
;BKPT UNBND-VRBL
> (baktrace)
BAKTRACE
+INTERNAL-UBV-BREAK← ARRAYCALL← PUSH← BUG←
It seems especially odd to me that things should blow up only after the
second call to bug.
-------
∂21-Aug-82 1207 Jonathan Rees <Rees at YALE> (SSTATUS SYNTAX #/| ...)
Date: Saturday, 14 August 1982 00:31-EDT
From: Jonathan Rees <Rees at YALE>
To: Bug-Lisp at MIT-MC
Subject: (SSTATUS SYNTAX #/| ...)
Cc: Ellis at YALE, Ruttenberg at YALE
Trying to set the syntax of | doesn't work.
(SSTATUS SYNTAX #/| 2.) ;2 is syntax of %, :, etc.
2
'|
/↑T
Vertical bars in symbols read as control-T's.
∂22-Aug-82 1558 Alan Bawden <ALAN at MIT-MC> (SSTATUS SYNTAX #/| ...)
Date: 22 August 1982 18:59-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: (SSTATUS SYNTAX #/| ...)
To: Rees at YALE
cc: BUG-LISP at MIT-MC, Ellis at YALE, Ruttenberg at YALE
Date: Saturday, 14 August 1982 00:31-EDT
From: Jonathan Rees <Rees at YALE>
(SSTATUS SYNTAX #/| 2.)
2
'|
/↑T
This is because (SSTATUS SYNTAX) doesn't know enough to set up the character
translation when it turns off a macro character. You can either do (SSTATUS
CHTRAN #/| #/|) immediately afterwords, or use (SETSYNTAX #/| 2. #/|) instead.
I started to fix this, but the code is too ugly to be believed.
∂22-Aug-82 1647 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
Date: 22 August 1982 19:29-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: push/defvst interaction?
To: BUG-LISP at MIT-MC
cc: Ruttenberg at YALE
Date: 14-Aug-82 10:55AM-EDT (Sat)
From: John Ruttenberg <Ruttenberg at YALE>
It seems especially odd to me that things should blow up only after the
second call to bug.
A smaller case of the bug:
(defvst bug-st
(a = (*array () t 10))
)
(defun bug (self member index)
(push member (arraycall t (bug-st-a self) index)))
(setq b (cons-a-bug-st))
(bug b 'a 4)
(bug b 'a 4)
After the first call to BUG it's definition has been changed to be:
(defun bug (self member index)
(push member (arraycall t <gensym> index)))
This is probably an artifact of PUSH being a fexpr (but thinking like a macro),
bug it also seems to depend heavily on the source of the array being a defvst
accessor. It doesn't happen if you are using defstruct instead. Perhaps those
responsible for defvst/push will step forward and fix?
∂22-Aug-82 1923 John Ruttenberg <Ruttenberg at YALE> Re: push/defvst interaction?
Date: 22-Aug-82 10:22PM-EDT (Sun)
From: John Ruttenberg <Ruttenberg at YALE>
Subject: Re: push/defvst interaction?
To: Alan at MIT-MC
Cc: Bug-Lisp at MIT-MC
In-Reply-To: Bawden's message of 22 August 1982 19:29-EDT
It doesn't happen if you are using defstruct instead.
We would use defstruct, except that using it into named hunks
makes it want to use some version of defvst that we don't have
here. Where are the authorative up to date sources for things
like defstruct and defvst? I'd like to know if we can get
this fix and others like it.
Also note that I don't seem to be able to compile the bug infested
code. (Same problem - some unbound gensym in the push expression).
-------
∂23-Aug-82 0001 George J. Carrette <GJC at MIT-MC> push/defvst interaction?
Date: 23 August 1982 02:45-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: push/defvst interaction?
To: Ruttenberg at YALE
cc: ALAN at MIT-MC, BUG-LISP at MIT-MC
As a bit of honest practical advice, I would concur with ALAN in
suggesting that you use DEFSTRUCT in preference to DEFVST.
The story goes like this: DEFVST was supposed to be part of
a package of code which was "NILCOM," common to both NIL and Maclisp,
and presumably to be part of "common-lisp." As it turned out though,
the implementation of all of that "NILCOM" code was too tentative
and kludgy to be worth bringing up in actual VAX NIL, so instead
code like Defstruct (which is de-facto common-lisp)
was brought up. So you see, there can be little
incentive here (at MIT) to support/fix-bugs in code such as DEFVST.
On the other hand, it is quite easy for me to make available to
you an option to defstruct called "EXTEND" which does the same
job as "DEFVST" except that the interface is a lot cleaner,
and it actually works! (It is what RLB and I used last summer to
cross-compile NIL from the pdp-10 to the VAX). You can get it
by FTPing "GJC;SFIX FASL" from the MIT-MC machine. Source is in
"GJC;SFIX >" on MIT-MC.
To answer your question about source code: The most up-to-date
versions of things are on the LIBDOC, LSPSRC, and NILCOM directories
on MIT-MC. The *best* solution seems to be to keep a winning
Maclisp environment working on MIT-OZ, and let people FTP
stuff from there.
-gjc
∂23-Aug-82 1409 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
Date: 23 August 1982 17:03-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: push/defvst interaction?
To: Ruttenberg at YALE
cc: BUG-LISP at MIT-MC
Date: 22-Aug-82 10:22PM-EDT (Sun)
From: John Ruttenberg <Ruttenberg at YALE>
It doesn't happen if you are using defstruct instead.
We would use defstruct, except that using it into named hunks
makes it want to use some version of defvst that we don't have
here. Where are the authorative up to date sources for things
like defstruct and defvst? I'd like to know if we can get
this fix and others like it.
I heve never released a version of defstruct that had anything whatsoever to do
with ANY of the out-of-core (autoloading) MacLisp libraries. There is a
feature that made defstruct a front end for defvst which I have never released
to anyone, but that wouldn't do you any good anyway. Can you send me an
example of a defstruct that tries to load ANYTHING? Up-to-date defstruct FASL
can be found on LISP;STRUCT FASL.
Also note that I don't seem to be able to compile the bug infested
code. (Same problem - some unbound gensym in the push expression).
I'm not surprised that you can't compile it either.
∂24-Aug-82 1545 Glenn S. Burke <GSB at MIT-ML> distribution request
Date: 24 August 1982 18:40-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: distribution request
To: TY at MIT-ML
cc: BUG-LISP at MIT-ML
tar@MIT-ML (Sent by ←←←036@MIT-ML) 08/24/82 14:48:02 Re: Phone message
Steve Cadrak called.
Academic Computing Center
University of Vermont
Burlington, VT 05405
He would like to obtain the latest MACLISP. (He has version 2009)
TOPS-20 version 5.
(802) 656-3910
∂24-Aug-82 1939 Greg Skinner <EE.GDS at MIT-OZ> Lisp problem
Date: 24 Aug 1982 2050-EDT
From: Greg Skinner <EE.GDS at MIT-OZ>
Subject: Lisp problem
To: bug-lisp at MIT-OZ
Subject: LISP problem
Is this a bug or just a feature? (especially (gcd 15 5)
evaluating to 1, while the others seem to evaluate correctly).
Plus, is there any way that LISP can be set so that base 10
numbers are echoed as such? (re 8 = 10 and 10 = 10)
[PHOTO: Recording initiated Tue 24-Aug-82 8:37PM]
TOPS-20 Command processor 4(661)-2
@lisp
LISP 2129
Alloc? n
*
(gcd 15 5)
1
(gcd 30 10)
10
(gcd 8 4)
4
(gcd 60 30)
30
(gcd 50 5)
5
(quotient 50 4)
12
50
50
(quit)
@pop
[PHOTO: Recording terminated Tue 24-Aug-82 8:38PM]
-------
∂24-Aug-82 1939 Barry Margolin at MIT-MULTICS Re: Lisp problem
Date: 24 August 1982 20:56 edt
From: Barry Margolin at MIT-MULTICS
Subject: Re: Lisp problem
Sender: Margolin.Multics at MIT-MULTICS
To: Greg Skinner <EE.GDS at MIT-OZ>
cc: bug-lisp at MIT-OZ
In-Reply-To: Message of 24 August 1982 20:50 edt from Greg Skinner
There were no bugs displayed in that session. By default, Maclisp is in
base 8, and 15(8) = 13(10) (where the notation xx(n) means the numeral
xx in base n), and the GCD of 5(10) and 13(10) is indeed 1. The
variables that control the base that numbers are input and output in are
"base", which is the base that numbers are output in, and "ibase", which
controls the input base. Associated with these is the variable
"*nopoint", which if set to T causes the decimal point that normally
follows decimal numbers on output to be suppressed. Note that any
fixnum that has a trailing decimal point (as in 100.) is also read in in
decimal, regardless of the setting of ibase, so to initially set the
base variables you should say:
(setq base 10.)
(setq ibase 10.)
∂27-Aug-82 1306 Glenn S. Burke <GSB at MIT-ML> (SSTATUS SYNTAX #/| ...)
Date: 27 August 1982 15:51-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (SSTATUS SYNTAX #/| ...)
To: Rees at YALE
cc: Ellis at YALE, Ruttenberg at YALE, BUG-Lisp at MIT-MC
I believe that SETSYNTAX is what you want here; it assumes that the
choices (bits only, MACRO, SPLICING) are mutually exclusive. (sstatus
syntax ...) only hacks the syntax bits. In obscure applications this
is actually useful (the fact that it doesn't clobber the macro/chtran
entry, that is), because you can do strange and perverse things with
something like "." so that it is still decimal point but also acts
like a special-token (implemented as a reader macro). (I've done this.
It almost works.)
∂29-Aug-82 2313 GSB@MIT-ML new format installed on MC and OZ
From: GSB@MIT-ML
Date: 08/30/82 01:34:11
Subject: new format installed on MC and OZ
GSB@MIT-ML 08/30/82 01:34:11 Re: new format installed on MC and OZ
To: (BUG LISP) at MIT-ML
format 827 has been put on MC and OZ. the file types involved are
FASL, BRACK, FLOAT, NUM, and UMACS. This fixes a fencepost bugs
in ~$ and a misfeature in operator definition via define-format-op,
and maybe some other things which i have since forgotten.
∂30-Aug-82 1613 JonL at PARC-MAXC Re: fixes to maclisp
Date: 30 Aug 1982 16:10 PDT
From: JonL at PARC-MAXC
Subject: Re: fixes to maclisp
In-reply-to: GJC's message of 20 August 1982 23:27-EDT
To: George J. Carrette <GJC at MIT-MC>
cc: JONL at MIT-MC, BUG-LISP at MIT-MC
I've just returned from two weeks travelling (LispConference, AAAI, MIT
visit etc) and I didn't see you at MIT -- are you still there?
There used to be a .CTL file on MIT-XX, PS:<MACLISP>ASSLIS.CTL, which
you could just SUBMIT and it would doo all the rest. It would leave
an *uninitialized* result on SS:<MACLISP>BBLISP.EXE.<nnnn> and also
do an initialization phase leaving PS:<MACLISP>XLISP.EXE.<nnnn> and
PS:<MACLISP>LISP.SYMBOLS.<nnnn>. You then rename XLISP to LISP after
certifying that things are winning. The value of the uninitialized
file is that it's hard to patch the LISP.EXE file with the existing NDDT since
it involves changing file page accessibilities (read-only etc).
∂30-Aug-82 2236 Kent M. Pitman <KMP at MIT-MC> FORMAT losing
Date: 31 August 1982 01:15-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Sender: VP at MIT-MC
Subject: FORMAT losing
To: GSB at MIT-MC
cc: BUG-LISP at MIT-MC
In Maclisp 2122, Format 827. on MIT-MC:
Ignoring the rough points in what these actually ask FORMAT to do ('cuz
there are a few conceptual bugs), these functions do not behave in ways
even remotely resembling what the LispM does with them. For example, the
LispM does not err, pdl-overflow, or complain of missing ~]'s. Simple
tests like (f nil), (f '(a)), (f '(a b)), (f '(a b c)) and likewise for g
should give you a feel for what I'm talking about. G'luck.
(defun f (x)
(lexpr-funcall #'format t "~#[nothing~;~S~;~S and ~S~
~:;~@{~<~% ~1,50:;~#[~1; and~] ~S~>~↑,~}~]" x))
(defun g (x)
(format t "~%;; ~{~<~%;; ~1,50:;~#[~1; and~] ~S~>~↑,~}.~%" x))
-kmp
∂31-Aug-82 2102 Glenn S. Burke <GSB at MIT-MC>
Date: 31 August 1982 23:57-EDT
From: Glenn S. Burke <GSB at MIT-MC>
To: BUG-LISP at MIT-MC
on OZ,
∂31-Aug-82 2107 Glenn S. Burke <GSB at MIT-MC>
Date: 1 September 1982 00:00-EDT
From: Glenn S. Burke <GSB at MIT-MC>
To: BUG-LISP at MIT-MC
on oz, an LH/| page disappears when the job is suspended and restarted.
One gets a memory protection violation...
∂31-Aug-82 2310 George J. Carrette <GJC at MIT-MC> hacking/assembly maclisp
Date: 1 September 1982 02:04-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: hacking/assembly maclisp
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC
Thanks for the info, now, I wonder if I have *read* access to the
Maclisp directory on XX? sigh... it is a wonder anything gets done
at MIT inside LCS. Yes, I expected to be at the lisp conference,
but when the time came to leave it seemed more fun to stay at
ATARI and hack up some demo's in NIL on their brand-new 780.
I heard that some of the graphics in TRON were done in Maclisp
on a Foonly (by the way). Remember that bug note/question about
extened objects and arithmetic some months ago? I think it
was from the same guy, Craig Renolds?
Anyway, thats the state of things, I'll be at ATARI again in a little
while and I'll give you a call in Palo Alto, want to see some
3-D graphics in NIL controlled via the flavor system?
[No, I didn't implement a number-compiler for NIL yet, the crunching
stuff is written in (sigh) "C" which gets interfaced to NIL in the
obvious way.]
-gjc
∂01-Sep-82 1043 Robert P. Krajewski <RpK at MIT-ML> WITH-OPEN-FILE
Date: 1 September 1982 13:40-EDT
From: Robert P. Krajewski <RpK at MIT-ML>
Subject: WITH-OPEN-FILE
To: BUG-Lisp at MIT-MC
cc: RpK at MIT-OZ
Does WITH-OPEN-FILE exist in MacLisp ? It would be a very nice
thing to have. I'd define a robust version of it, but I don't
know how MacLisp does UNWIND-PROTECTs and such. (If you take
out the clean-up code, it's very simple.)
This may be a stupid question, but why don't the objects
returned by OPEN accept messages like :TYO, :TYI, :STRING-OUT,
:LINE-OUT, :TRUENAME, and so on ? All they seem to accept are
very general messages that would be handled by the Lisp Machine
SI:VANILLA-FLAVOR -- :PRINT-SELF and others.
``Bob''
∂01-Sep-82 1333 Kent M. Pitman <KMP at MIT-MC> WITH-OPEN-FILE
Date: 1 September 1982 16:27-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: WITH-OPEN-FILE
To: RPK at MIT-MC
cc: BUG-LISP at MIT-MC
There is a package on LIBLSP called IOTA which does what you want. I'm working
on a library of macros and functions to help people trying to hack Lisp
Machine compatibility. Among things in that library will be WITH-OPEN-FILE.
For now, though, IOTA is the thing to use. It's used heavily in lots of Maclisp
systems and works fine. Documentation is in LIBDOC;IOTA >
-kmp
∂01-Sep-82 1403 Alan Bawden <ALAN at MIT-MC> WITH-OPEN-FILE
Date: 1 September 1982 16:56-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: WITH-OPEN-FILE
To: RpK at MIT-ML
cc: BUG-LISP at MIT-MC, RpK at MIT-OZ
Date: 1 September 1982 13:40-EDT
From: Robert P. Krajewski <RpK at MIT-ML>
Does WITH-OPEN-FILE exist in MacLisp ? It would be a very nice
thing to have. I'd define a robust version of it, but I don't
know how MacLisp does UNWIND-PROTECTs and such. (If you take
out the clean-up code, it's very simple.)
MacLisp does UNWIND-PROTECT by having an UNWIND-PROTECT special form just like
the LispMachine's. There is no built-in WITH-OPEN-FILE macro, but clearly you
can write your own using UNWIND-PROTECT, or wait until KMP writes one (he'll
think of some screws you never dreamed of I'll bet) or you can convert your
code to using IOTA.
This may be a stupid question, but why don't the objects
returned by OPEN accept messages like :TYO, :TYI, :STRING-OUT,
:LINE-OUT, :TRUENAME, and so on ? All they seem to accept are
very general messages that would be handled by the Lisp Machine
SI:VANILLA-FLAVOR -- :PRINT-SELF and others.
I don't understand this question in the least. The objects returned by OPEN
don't except ANY messages. They are not message recieving objects. They do
have a printed representation, but that isn't accomplished by sending any
messages. You don't do I/O by sending them messages, but by calling functions
like PRINC and TYO and passing them the "file object" as an argument.
∂01-Sep-82 1958 Glenn S. Burke <GSB at MIT-MC> renamef failure
Date: 1 September 1982 22:52-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: renamef failure
To: BUG-LISP at MIT-MC
the IOJRST at RENAM5+6 should be a JFCL. If the RNAMF fails then the
file has been closed but the jfn not released. The IOJRST after the
failing CLOSF will clobber the first error message (and probably not
allow the error to return because iojrst stack hacks probably aren't
additive). I have changed this in the source, someone patch it on
a 20?
∂01-Sep-82 2045 FEINBERG at CMU-20C renamef failure
Date: 1 September 1982 23:36-EDT (Wednesday)
From: FEINBERG at CMU-20C
To: Glenn S. Burke <GSB at MIT-MC>
Cc: BUG-LISP at MIT-MC
Subject: renamef failure
Howdy!
It is patched on OZ.
--Chiron
∂01-Sep-82 2227 Kent M. Pitman <KMP at MIT-MC>
Date: 2 September 1982 01:19-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: RPK at MIT-MC
cc: BUG-LISP at MIT-MC
I put a package on LIBLSP; (and <LIBLSP> on OZ) called LISPM. Please play
with this and tell me if it gives you any troubles. If no one reports any
bugs in a week or two, I'll announce it to INFO-MACLISP. The file defines
compatibility definitions for DEFSUBST, DOLIST, DOTIMES, MEXP, WITH-OPEN-FILE
and WITH-OPEN-STREAM. Documentation is in LIBDOC;LISPM > and in
OZ:PS:<LIBLSP>LISPM.LSP
-kmp
∂06-Sep-82 1540 Devon S. McCullough <Devon at MIT-ML>
Date: 6 September 1982 18:39-EDT
From: Devon S. McCullough <Devon at MIT-ML>
To: BUG-lisp at MIT-OZ
In lisp in Remote-File 14.0, LMFILE-Remote 18.0, MIT-Specific 10.0,
System 87.19, Experimental ZMail 46.3, microcode 164, No, devon,
on Lisp Machine One:
In the blue manual on page 158, 11.1 describing closures, it says
The form (closure var-list function), where var-list is a list of...
...
the value cells of the symbols. Then function is applied to the ARGUMENT. (This...
in the next-to last paragraph on the page. ARGUMENT should be plural, or I'm mixed up!
∂06-Sep-82 1544 Kent M. Pitman <KMP at MIT-MC>
Date: 6 September 1982 18:38-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: BUG-LISP at MIT-MC
I forwarded DEVON's bug report to BUG-LISPM where it should have gone.
∂06-Sep-82 1827 Robert Elton Maas <REM at MIT-MC> (LISTEN)
Date: 6 September 1982 21:20-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: (LISTEN)
To: BUG-LISP at MIT-MC
Why does (LISTEN) take about 100 miliseconds (0.1 second) to execute?
This seems to be a very long time.
∂07-Sep-82 1329 Glenn S. Burke <GSB at MIT-ML> (LISTEN)
Date: 7 September 1982 16:07-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (LISTEN)
To: BUG-LISP at MIT-MC
i replied to REM
∂07-Sep-82 1737 Glenn S. Burke <GSB at MIT-MC> suspend tty code fix (tops-20 vts)
Date: 7 September 1982 18:46-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: suspend tty code fix (tops-20 vts)
To: BUG-LISP at MIT-MC
cc: mt at MIT-OZ
According to MT, the problem is that Lisp is setting a whole
word with stmod rather than only the left half as it should;
this can be fixed by making it do RTMOD, and then HLL 2,TI.ST6
rather than the MOVE it now does, at OPNT2+twentysome.
This has been fixed in the source, and patched into the BBLISP on OZ.
We made a .EXE, but did not install it on <SUBSYS> yet (it was in use).
∂07-Sep-82 1738 Skef Wholey <Wholey at CMU-20C> Complr's losing lossage, of course
Date: Tuesday, 7 September 1982 20:14-EDT
From: Skef Wholey <Wholey at CMU-20C>
To: Bug-Complr at MIT-MC
Subject: Complr's losing lossage, of course
Let's see what complr does with the following code:
-----
;;; -*- Lisp -*-
;;;
;;; COMPLR LOSSAGE!!!
;;;
(defconst const-1 0)
(defconst const-2 3)
(defmacro combine-somehow (a b)
`(deposit-byte ,b 28 4 ,a))
(defun fleep ()
(print (combine-somehow const-1 const-2))
(print (combine-somehow const-2 const-1))
(print (combine-somehow 0 3))
(print (combine-somehow 3 0)))
-----
When compiled, (fleep) prints the following:
3
0
3
805306368
Seems a little bogus, huh?
[I realize that no one does much MacLisp maintainence these days, but I just
needed someone to flame at...]
--Skef
∂07-Sep-82 2221 Glenn S. Burke <GSB at MIT-MC> load-byte/deposit-byte miscompilation
Date: 8 September 1982 00:55-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: load-byte/deposit-byte miscompilation
To: Wholey at CMU-20C
cc: BUG-COMPLR at MIT-MC
I have identified the problem in the source, but not tested or
installed the fixes yet (get to it tomorrow). There were a
couple things wrong. Stay tuned...
∂09-Sep-82 0021 GSB@MIT-ML previous patch, to OPNT2
From: GSB@MIT-ML
Date: 09/09/82 03:20:05
Subject: previous patch, to OPNT2
GSB@MIT-ML 09/09/82 03:20:05 Re: previous patch, to OPNT2
To: (BUG LISP) at MIT-ML
is incorrect. I'll publicize the correction when i stop being shafted
by losing hardware, and when i go over it with a Travers
∂13-Sep-82 1324 Kent M. Pitman <KMP at MIT-MC>
Date: 13 September 1982 16:18-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: ALAN at MIT-MC
cc: BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML
It's sort of a bug in Autokeep (or maybe in Twenex) that you can't set
the Autokeep bit for an entire cluster of files and have it apply to new
versions when written. I think what happened is that when Glenn wrote the
patch the other night to fix SUSPEND lossage, he didn't set the autokeep
bit back on. This was not so much an issue of OZ policy or anything silly
like that as just an easy slip to have happen. This is yet another good
reason why <SUBSYS>MACLISP should probably be an unchanging .EXE file
which does nothing more than reload some other file (such as <MACLISP>'s
MACLISP.EXE). I think this is what is done on EE and I think the reasons
are similar. In any case, sorry for your lost work. It was not intended
that it shouldn't be kept.
-kmp
∂14-Sep-82 1102 Jonathan Alan Solomon <JSol at USC-ECLC>
Date: Tuesday, 14 September 1982 10:52-PDT
From: Jonathan Alan Solomon <JSol at USC-ECLC>
To: David C. Plummer <DCP at MIT-MC>
Cc: ALAN at MIT-MC, BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML,
KMP at MIT-MC
Address: 3737 South Hoover Street Room PHE 204
Los Angeles, California 90089-0273
Phone: (213) 202-1793
Yes for V5, If you save a <SYSTEM>EXEC.EXE properly with this switch
set it will remain set for everyone. Individual users who want to
change it can simply unset it in their COMAND.CMD files.
In my exec there already exists a command to override the file
setting. People seem to be doing SET FILE (no) EPHEMERAL and (no)
AUTOKEEP at random and whenever they feel like it. If you INSTALL LISP
SYS:LISP.EXE AUTOKEEP NO CONFIRM you will *always* get a Kept lisp no
matter what anyone does to the file (this is in my exec under v4).
--JSol
∂14-Sep-82 2252 Stavros M. Macrakis <MACRAK at MIT-MC> < WNA msg
Date: 15 September 1982 01:50-EDT
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject: < WNA msg
To: BUG-LISP at MIT-MC
(< 4.5 3)
;4.5 fixnum cant compare to flonum
args=4.5
(return '(4))
...still unhappy...
(return '(3.4))
...happy...
∂17-Sep-82 1643 Glenn S. Burke <GSB at MIT-ML> (status ttysize) on 20X
Date: 17 September 1982 19:44-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (status ttysize) on 20X
To: ALAN at MIT-MC
cc: BUG-lisp at MIT-MC
Fixed in the source, STATUS 259 (hohoho). The sign bit is used for
(status terpri) on a per-file basis, and things like LINEL and this
code have to be careful to use magnitude only. I will patch this in
on OZ and XX shortly.
(sstatus terpri t [file]) sets this; it is probably being done by something
you load up.
∂17-Sep-82 1658 GSB@MIT-ML (status ttysize) bug, 20x
From: GSB@MIT-ML
Date: 09/17/82 19:46:34
Subject: (status ttysize) bug, 20x
GSB@MIT-ML 09/17/82 19:46:34 Re: (status ttysize) bug, 20x
To: (BUG LISP) at MIT-ML
i should have said, STTYS1+1 should use MOVM rather than MOVE.
∂17-Sep-82 1701 GSB@MIT-ML previous patch
From: GSB@MIT-ML
Date: 09/17/82 19:57:35
Subject: previous patch
GSB@MIT-ML 09/17/82 19:57:35 Re: previous patch
To: (BUG LISP) at MIT-ML
well it's patched in the bblisp on oz.
The scheme dump shares with lisp on the wrong dir so i can't replace
the <maclisp> copy, and XX is wedged in such a way that i can only
get in via telnet which seems to interpret <cr> as <lf> in nddt.
∂01-Oct-82 0404 Kent M. Pitman <KMP at MIT-MC> More data
Date: 1 October 1982 07:01-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: More data
To: BUG-LISP at MIT-MC
cc: JPG at MIT-MC
Well, my feeling is that people shouldn't rely on the exact truth value
which comes back from a true/false predicate. Sad that it ws documented
like that.
By the way, here's some more data. There seems to be a pattern:
Arg1 Arg2 Return Value
A AB T
AB ABC T
ABC ABCD T
ABCD ABCDE T
ABCDE ABCDEF LESSP
ABCDEF ABCDEFG T
ABCDEFG ABCDEFGH T
ABCDEFGH ABCDEFGHI T
ABCDEFGHI ABCDEFGHIJ T
ABCDEFGHIJ ABCDEFGHIJK LESSP
ABCDE ABCDEFG LESSP
Looks like when the characters match exactly up to the length of the first
symbol and the second symbol's pname continues on, the symbol LESSP is
returned. Pretty odd.
∂02-Oct-82 1234 Alan Bawden <ALAN at MIT-MC> ALPHALESSP: More data
Date: 2 October 1982 15:31-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: ALPHALESSP: More data
To: BUG-LISP at MIT-MC, JPG at MIT-MC, KMP at MIT-MC
Date: 1 October 1982 07:01-EDT
From: Kent M. Pitman <KMP>
Looks like when the characters match exactly up to the length of the first
symbol and the second symbol's pname continues on, the symbol LESSP is
returned. Pretty odd.
The fix is to patch the MOVEI D,QLESSP at ALPHAL to be MOVE D,VT.ITY
It only seems to matter whether D contains NIL or non-NIL except that the
contents of D get returned in the special case that JPG discovered.
∂29-Oct-82 1519 Alan Bawden <ALAN at MIT-MC> [TONYH: forwarded] (bug-PROGRAM??????)
Date: 29 October 1982 18:17-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: [TONYH: forwarded] (bug-PROGRAM??????)
To: BUG-LISP at MIT-MC
Date: 29 October 1982 17:56-EDT
From: TONYH at MIT-AI
To: BUG-PROGRAM at MIT-AI
I have three little problems which defy all of the info we have here.
If anyone can offer any help or suggestions we'd be very grateful.:
(1) Macros which are compiled in one file cannot be called from
another file if the latter is also compiled. The error message is
MACRO NOT PERMITTED IN UUO CALL. We think it must be something to
do with the declarations made at the tops of files for the compiler's
sake, but we have no information about them, and all our guesses based on
MacLisp source files have failed;
(2) We have tried to make the tilde a special readmacro. The idea is that special
comments within a file (they're quoted strings) should be prefaced by the tilde,
and that when the file is loaded the readmacro will place these comments
into a HELP system. The file containing the readmacro definition is
compiled, and the idea works well as long as the files subsequently loaded
(those with the tilde-ised comments in) are not compiled. The readmacro won't
work on FASL files , including its own file.
Also, does anyone happen to know how to stop typed-in characters from
being echoed back to the terminal? I'm trying to build alittle keypad-
driven editor, but my keypad (VT52) sends three characters at once,
which I'd rather not see!
Oh - I've just remembered another one. Our MacLisp occasionally has fits
of GC←DAEMON errors involving STRING-COMPRESS-SPACE, and frankly none of
us can understand the source code which might tell us why...
Many thanks in advance to anyone who can help, from the very heart of
quaint little old England.
Tony.
∂29-Oct-82 1702 JONL at PARC-MAXC Your recent note on MacLisp errors
Date: 29 OCT 1982 1700-PDT
From: JONL at PARC-MAXC
Subject: Your recent note on MacLisp errors
To: TONYH at MIT-AI
cc: BUG-LISP at MIT-MC
Your questions (1) and (2) arise from misunderstanding how and
when macros are applied (both readmacros and interpreter/compiler
macros).
1) Macros are never "called" in the sense that we think of calling
a funciton -- they are "expanded" by the interpreter and compiler,
but of course if they are not available to the compiler when compiling
some file, then no expansion can be done, and the compiler will defaultly
assume that the unknown name stands for a function call (rather than for
some macro to be expanded).
2) when READing a file, the s-expressions are stored as ascii text, and
the readmacro characters are invoked when such character is encountered
by the READer; FASL files, on the contrary, store either the
compiled versions of programs, or a special internal-format for other
s-exressions. Perhaps a reasonable approach is for the tilde macro
merely to append to some global list, which is then output near the end of
your file. Thus both ascii files being READ and compile dFASL files would
have a consistent representation of what is wanted in the HELP system (namely,
the list of goodies which was produced by READing the ffile in the first place).
As for deletion of the echo, it will depend on what kind of system you are using
TOPS10 or TOPS20. If the latter, you can turn of echoing by an appropriate STATUS
call which sets the bits in the TOPS20 echocontrol words; There may be some explanation
of this (i.e., the extended STATUS calls for TOPS20) in the note which I used to
attach to the distributed MacLisp tapes.
As for the GCDAEMON reported errors, it sounds like you have a copy of the STRING
package from early to mid 1980. Many bugs in it were fixed in late 1980 and
very early 1981, so these problems should go away if you can get the current
distribution (which was supposed to have taken place just as I was leaving MIT
in mid March of this year.)
More hints on problems (1) and (2)
Thus usual procedure for using "compiled" macros is to seperate them out
into a file by themselves, and have them loaded into the compiler each time
you compile some file which might use some of them. Admittedly this is not quite
as nice as defining the macros where they might "naturally" occur, but . . .
Suppose you have your tilede macro collect some data into TILDELIST. Then at the
end of the file you could put a form
(SETQ DATASTUFF '#.TILDELIST)
this wouold be one way of insureing that DATASTUFF would have the save value after
loading the FASL file as when loading thee source file.
∂31-Oct-82 1132 TONYH at MIT-AI
Date: 31 October 1982 13:05-EDT
From: TONYH at MIT-AI
To: BUG-LISP at MIT-AI
Dear JONL -
Thank you very much for your help. Unfotunatley, in trying to make
use of it ZI seem to have made things worse, to such an extent that the system
itself pleaded with me to call you again. I'd better show you what I'm
doing - you'll probably see at a glance what horrors I'm perpetrating on your
long-suffering MacLisp:
(declare (SETQ DEFMACRO-FOR-COMPILING 'T DEFMACRO-DISPLACE-CALL 'T)
(special helplist))
;;; During loading, the tilde (~) readmacro allows the special comments
;;; in this file to be stored for later access by the APROPOS function.
;;; On the property-list of 'HELP, under the property 'COMMENTS, will
;;; be found a list of the comments, each element being a dotted pair
;;; of the unquoted part of the comment and the quoted part.
(eval-when (compile load)
(and (status feature COMPLR)
(own-symbol DEFREADMACRO /~-readmacro))) ;superstition...
(eval-when (eval load compile)
(setq helplist nil)
(defmacro defreadmacro (char &rest body)
(let ((macro-name (symbolconc char '-readmacro)))
(setsyntax char 'macro macro-name)
`(defun ,macro-name () ,.body)))
(defreadmacro /~
(let* ((/↑q t) (comment `(,(read) ,[atsign](read))))
(push comment helplist)
t)))
[atsign] intended to represent the symbol on this machine!
Then follows the comment itself:
~MSG "Simple formatter..."
...and the function it is supposed to describe - also a macro. Then,
a line I added in the belief that it was the kind of thing you were advising:
(putprop 'help '#.helplist 'comments)
That's the end of the file. I then tried to compile it:
;BKPT DATA So I did:
$p
(COMMENT **ERROR** #75526 Unrecognizable datum ←← Collecatoms in function FOO)
; %%%%%%%%%%%%%%%%%%%%COMPILER ERRO(R - CALL JONL%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
;BKPT BARF
Ugh, what have I done? Sorry to bother you with this again so soon. I would
have flogged on with it on my own except for what the machine said just there.
As to your other valuable help - yes, I had just about reached the same
conclusion regarding how to re-use "compiled" macros. I just hoped,
(we are riddled with superstition here) that there might be a clever way
around the problem. We seem to have the May '82 version of STRING, but
I'll check that the dates are right. And Lord alone knows what happened
to any notes you included with the source tapes - such things go
through many administrative hands before reaching poor hackers like us!
Thank you again, anyway.
Tony.
∂31-Oct-82 1308 George J. Carrette <GJC at MIT-MC> lossage after lossage
Date: 31 October 1982 16:04-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: lossage after lossage
To: TONYH at MIT-AI
cc: BUG-LISP at MIT-MC
It doesn't help to be superstitious about Maclisp. In fact, it helps a lot
to keep things as simple as possible, not using a feature unless you
really understand what it is doing. Here is what I recommend:
(1) In one file, put your "compile-time" environment. This includes
macros and readmacros, and special declarations, e.g.
(herald macros)
(defvar helplist)
(defun help-comment-readmacro ()
(push (cons (read) (read)) helplist))
(setsyntax #/~ 'macro 'help-comment-readmacro)
(defmacro helplist-begin ()
(setq helplist ())
(defmacro helplist-end ()
`(defprop help ,helplist comments))
;; Note that I didn't bother with defining a fancy DEFREADMACRO, since
;; it just isn't worth the trouble.
(2) Then your source-file would look like :
(eval-when (eval compile)
(or (get 'macros 'version) (load "macrofile")))
(helplist-begin)
.... stuff stuff stuff ...
(helplist-end)
(3) Do not use the Maclisp string package. It is has proven to
be completely unreliable. An alternative, which has been used in a text
editor written in maclisp, is in "GJC;CHAR >" on MIT-MC.
Someday a reasonable string may be released as part of the Maclisp
distribution, until then you should be able to get by fine with
something like "GJC;CHAR >"
Note that this file should be loaded at COMPILE and RUNTIME,
since it includes declarations, readmacros, and code.
-gjc
∂01-Nov-82 1417 David Eppstein <CSD.Kronj at SU-SCORE> SUBFORK module (LEDIT)
Date: 1 Nov 1982 0055-PST
From: David Eppstein <CSD.Kronj at SU-SCORE>
Subject: SUBFORK module (LEDIT)
To: Bug-LISP at MIT-MC
The lines in SI:GIVUP-TTYINTS that set the inferior fork's capabilities
are switched, so that the fork gets no caps, causing LEDIT to lose big.
Old code:
(jsys #.EPCAP handle
(boole 2 1←18 cap←inferior)
(boole 2 1←18 cap←poss←inf)
1)
Correct code:
(jsys #.EPCAP handle
(boole 2 1←18 cap←poss←inf)
(boole 2 1←18 cap←inferior)
1)
David
-------
∂03-Nov-82 2158 JONL at PARC-MAXC 4th level indirection -- maybe you haven't yet seen this?
Date: 3 NOV 1982 2058-PST
From: JONL at PARC-MAXC
Subject: 4th level indirection -- maybe you haven't yet seen this?
To: info-lisp at MIT-AI, info-lispm at MIT-AI
cc: gls at MIT-AI, rpg at MIT-MC
Date: 3 Nov. 1982 1:49 pm PST (Wednesday)
From: Treichel.PA
Subject: Lisp Song
To: CIS↑
Reply-To: Treichel
Have you seen this?
Jeanie
---------------------------
Date: 3 Nov. 1982 4:23 pm EST (Wednesday)
From: Gafter.Henr
Subject: LISP song
To: AllWhimsy↑.pa, Language↑, Gottwald, KAnderson
cc: Gafter
This was in the uucp bboard net.jokes recently.
-------------------------------------------------------
From decvax!utzoo!utcsrgv!roderick Mon Nov 1 14:24:35 1982
Another Glitch in the Call
------- ------ -- --- ----
(Sung to the tune of a recent Pink Floyd song.)
We don't need no indirection
We don't need no flow control
No data typing or declarations
Hey! Did you leave the lists alone?
Chorus:
All in all, it's just a pure-LISP function call.
We don't need no side effect-ing
We don't need no scope control
No global variables for execution
Hey! Did you leave those args alone?
(Chorus)
We don't need no allocation
We don't need no special nodes
No dark bit-flipping in the functions
Hey! Did you leave the bits alone?
(Chorus)
We don't need no compilation
We don't need no load control
No link edit for external bindings
Hey! Did you leave that source alone?
(Chorus, and repeat)
------------------------------------------------------------
∂20-Nov-82 1508 GJC at MIT-MC FLAME warning: Scheme broken on OZ today.
Date: Saturday, 20 November 1982 18:03-EST
Sender: GJC at MIT-OZ
From: GJC at MIT-MC
To: GLR at MIT-OZ
Cc: BUG-LISP at MIT-OZ, FEINBERG at MIT-OZ, GJS at MIT-OZ, HAL at MIT-OZ,
HANSON at MIT-OZ, RWK at SCRC
Subject: FLAME warning: Scheme broken on OZ today.
In-reply-to: The message of 20 Nov 1982 15:43-EST from GLR
You would patch Maclisp without knowing who was doing maintenance and
where the canonical sources are? Sigh...
As of now there is no Local Maclisp maintenance, and no canonical sources.
When OZ came up I was to install Maclisp here from sources on MC and XX,
but instead MARTY cleverly arranged for people outside of MIT and the LAB to
"help him out" thereby contributing to the present inconsistent mess.
However, things seemed to run anyway, so it wasn't worth hassling, considering
the amount of other work to do on other projects.
On the other hand, when I try to run SCHEME on OZ to verify examples run
in other implementations (in this case on the VAX), I don't like to end up
spending lots of time hassling MACLISP and lack of DISK SPACE on OZ.
(Who ?designed? the present disk-structure settup here anyway?
With all those RP06's, why are we losing? Doesn't anybody GFR?)
If you have problems with Maclisp on TOPS-20, first try to get around
them by loading LISP-LEVEL stuff, and dumping out your own version using SHARE.
The mere fact that you had INTERLOCK problems with trying to patch LISP.EXE
should have told you that somebody was depending on it.
The present problem is just that the most experienced Maclisp user/implementor
people here at the labs don't find it worthwhile to fix maclisp bugs in
the MIDAS sources. Mainly because they are responsible for or depend on
stable large systems in the present versions of Maclisp, and because they
have new implementations of lisp systems to work on.
To push forward the maclisp world for the sake of small changes is
conterproductive, as a small time spent by inexperienced hackers
can force the spending of considerable time by experienced hackers.
This is a very expensive form of MAKE-WORK. (Real $$$ expensive too.)
-GJC
p.s. In other words. Cool it for a while in the Maclisp directory.
After the Thanksgiving break you can talk with GSB, myself, and others
about what changes are really needed.
∂20-Nov-82 1932 David C. Plummer <DCP at MIT-MC> Re: Scheme broken on OZ today.
Date: 20 November 1982 22:25-EST
From: David C. Plummer <DCP at MIT-MC>
Subject: Re: Scheme broken on OZ today.
To: RWK at SCRC-TENEX
cc: GJC at MIT-MC, GLR at MIT-OZ, FEINBERG at MIT-OZ, HAL at MIT-OZ,
GJS at MIT-OZ, HANSON at MIT-OZ, BUG-LISP at MIT-OZ
You want to make separate code and data spaces for the current
MACLISP, do you?? Well, FORGET IT!!! Perhaps you should get
Gorin's book on TWENEX assembler and read the section on extended
addressing.
Basically, CAR and CDR won't work. Well, it might have a prayer
if the CODE for CAR and CDR were in the DATA section. This goes
for all other code that does a CAR or CDR. Well, then again, you
might be able to get around that by making CAR and CDR be two
instructions instead of one. The second instruction would set
the left half to be the DATA section. Kludge, kludge, kludge.
Now what about all those other primitive LISP operators??
That is not the right solution. The right solution is to
reimplement 'Lisp' for extended addressing machines. For 2060's
this would give you 31 address spaces (assuming you can't do much
useful stuff in section 0). On the Jupiter I think the number
jumps to 4095 (and then all you need is several dozen disk drives
for paging).
I know of at least one effort to write an extended addressing
superset of Common Lisp. How much MACLisp code will need to be
modified or rewritten probably depends on how well it was written
for portability in the first place.
My feable knowledge of Common Lisp forces me to make the
following warnings:
* Expect your programs to get bigger. CONSes will take up two
words instead of one.
* Fixnums may shrink to 32 (or even 30) bits. Overflow will cons
bignums.
* Expect arithmetic operations to slow down. I think Common Lisp
does generic arithemetic. If so, a simple + on non-declared
numbers needs to check the arguments and value (even in compiled
code).
∂21-Nov-82 2357 Martin David Connor <MARTY at MIT-MC> A minor update for Top-20 Maclisp
Date: 22 November 1982 02:46-EST (Monday)
Sender: MARTY at MIT-OZ
From: Martin David Connor <MARTY at MIT-MC>
To: GSB at ML
Subject: A minor update for Top-20 Maclisp
Cc: Bug-Lisp at MC
I found the following in MC:L;STATUS >
Specifically in the (sstatus ttyint ... ) code:
...
SSTIN1: HRRM B,(TT)
...
IFN D20,[
POP P,TT ;RESTORE TTSAR
ROT F,1 ;RESTORE CHARACTER
CAIE F,3 ;DON'T ALLOW USE TO ASSIGN ↑C
==> CAILE F,26. ;TOPS-20 ONLY SUPPORTS TO ↑Z
| JRST UNLKTRUE ;RETURN TRUE, BUT DON'T DO TELL THE OP SYS
| ...
|
= Well, this perhaps used to be true, but is no longer. these days,
one can assign several other characters.
I think the update I would suggest is to remove the test altogether,
since the bit values for the interrupt word on the 20 after the
altmode would have to be special cased.
For my particular application I need to get control at interrupt
I made myself a patched lisp until this is changed, and I indeed am
able to get the altmode interrupt properly.
∂19-Dec-82 1947 JONL at PARC-MAXC Re: (\ x 0) revisited, revisited, revisited
Date: 19 DEC 1982 1945-PST
From: JONL at PARC-MAXC
Subject: Re: (\ x 0) revisited, revisited, revisited
To: ALAN at MIT-MC
cc: BUG-LISP at MIT-MC, GSB at MIT-ML, JONL
In response to your message sent 19 December 1982 21:00-EST
It has always been the case that MacLisp's "single-character"
arithmetic functions were driven by the desire for open-compilation.
Thus one gives up any interpreter error checking in the compiled
code, merely accepting what the hardware returns. It's certainly
no surprise, then, that the PDP10 does odd things with division by
zero -- or do I mistake the tone of your note?
By the bye, I had to bring in the generic operation, since the
"right" thing for the \ subr to do is to cause an error when
given a 0 divisor (just as it would if you gave it NIL for an arg);
unfortunately, this may not be the right thing to do to "fix" the
REMAINDER function: see the caveat in my previous msg.
∂19-Dec-82 2023 Glenn S. Burke <GSB at MIT-ML> Re: Re: (\ x 0) revisited, revisited, revisited
Date: 19 December 1982 23:20-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: Re: Re: (\ x 0) revisited, revisited, revisited
To: jonl at PARC-MAXC
cc: BUG-lisp at MIT-MC
No, the whole point of this proposal is that the "right" thing to do
is not to cause an error for a zero divisor, but to check for that
and "do the right thing". This is predicated on the premise that for
the REMAINDER operation, a 0 divisor has a defined result.
(Presumably someone else once thought this, given that the REMAINDER
function has this check.)
The \ function is not an interface to the second value returned by the
IDIV instruction. Our semantics are just that the interpreted version
will behave compatibly with the compiled one. If it takes an extra
couple of instructions to do it right, then great. (HAULONG takes a
couple instructions, as do some of the fix-float conversions.)
∂26-Dec-82 1917 PB e-subjob communication
To: BUG-e, BUG-lisp
What happens when a subjob has lots of output for a window that you are not
looking at? If, as I assume, it suspends the job once some small buffer
is filled, this is a lose, since I often want to get a bunch of output while
doing something else. Or am I wrong, and I can do that?
∂08-Jan-83 1147 EB @ MIT-MC
Date: Saturday, 8 January 1983 14:36-EST
Sender: EB @ MIT-OZ
From: EB @ MIT-MC
To: Bug-Lisp @ MIT-OZ
Does OZ have the latest Maclisp? Lisp 2129, which is installed there,
still has the bug wherein it opens JFNs in restricted mode.
∂11-Jan-83 1506 EB @ MIT-MC
Date: Tuesday, 11 January 1983 13:46-EST
Sender: EB @ MIT-OZ
From: EB @ MIT-MC
To: Bug-Lisp @ MIT-OZ
There is no ALARMCLOCK function in Lisp 2129 on Oz. Is the lack of
ALARMCLOCK permanent?
∂21-Jan-83 1441 JOSHM at MIT-OZ How do I...
Date: 21 Jan 1983 1737-EST
From: JOSHM at MIT-OZ
Subject: How do I...
To: info-lisp at MIT-OZ
cc: bug-lisp at MIT-OZ, bug-scheme at MIT-OZ, info-scheme at MIT-OZ
How do turn off input echoing from inside maclisp or scheme? I'm
writing a display oriented program and the typed input keeps destroying
the display.
-Josh
-------
∂21-Jan-83 1448 JOSHM at MIT-OZ at MIT-MC How do I...
Date: 21 Jan 1983 1737-EST
From: JOSHM at MIT-OZ at MIT-MC
Subject: How do I...
To: info-lisp at MIT-OZ at MIT-MC
cc: bug-lisp at MIT-OZ at MIT-MC, bug-scheme at MIT-OZ at MIT-MC,
info-scheme at MIT-OZ at MIT-MC
How do turn off input echoing from inside maclisp or scheme? I'm
writing a display oriented program and the typed input keeps destroying
the display.
-Josh
-------
∂21-Jan-83 1850 Feinberg@CMU-CS-C How do I...
Received: ID <FEINBERG@CMU-CS-C>; 21 Jan 83 21:43:21 EST
Date: 21 Jan 83 21:43:19 EST
From: Feinberg@CMU-CS-C
To: JOSHM%MIT-OZ@MIT-MC
Cc: bug-lisp%MIT-OZ@MIT-MC, bug-scheme%MIT-OZ@MIT-MC
Subject: How do I...
In-reply-to: The message of 21 Jan 1983 17:37-EST from JOSHM at MIT-OZ at MIT-MC
Hi.
Load <MACLISP>TTY.FASL, and use DO-WITH-TTY-OFF, like so:
(DO-WITH-TTY-OFF <form1> <form2> ... <formn>) ;Like a PROGN with echo
--Chiron
∂14-Feb-83 2041 Communications Satellite <COMSAT @ MIT-MC> Msg of Monday, 14 February 1983 20:12 EST
Received: from SRI-AI by SU-AI with NCP/FTP; 14 Feb 83 20:40:24 PST
Received: from MIT-MC.ARPA by SRI-AI.ARPA with TCP; Mon 14 Feb 83 18:27:43-PST
Date: 14 February 1983 21:02 EST
From: Communications Satellite <COMSAT @ MIT-MC>
Subject: Msg of Monday, 14 February 1983 20:12 EST
To: MacLisp @ SRI-AI
ReSent-date: Mon 14 Feb 83 20:38:37-PST
ReSent-from: MacLisp Hackers <MacLisp@SRI-AI.ARPA>
ReSent-to: buglisphack@SU-AI.ARPA
FAILED: BUGLISPHACK at SU-AI; Host appears to be permanently down or not accepting mail.
Failed message follows:
-------
Received: from SRI-AI.ARPA by SU-SCORE.ARPA with TCP; Mon 14 Feb 83 14:43:12-PST
Date: Mon 14 Feb 83 14:40:50-PST
From: MacLisp Hackers <MacLisp@SRI-AI.ARPA>
Subject: Re: I really don't know where to send this one...
To: NCP.EGK@SU-GSB-HOW.ARPA, Bug-Oz%mit-Oz@SU-SCORE.ARPA,
Bug-Lisp%MIT-Oz@SU-SCORE.ARPA, daniel%mit-Oz@SU-SCORE.ARPA,
Gumby%mit-Oz@SU-SCORE.ARPA
In-Reply-To: Your message of Sun 13 Feb 83 13:15:11-PST
There ISN'T a SYS:MACLISP.EXE on OZ!
-------
∂05-Apr-83 1711 Alan Bawden <ALAN @ MIT-MC> buglisphack@sail
Received: from USC-ECL by SU-AI with NCP/FTP; 5 Apr 83 17:11:14 PST
Received: from MIT-MC by USC-ECL; Tue 5 Apr 83 17:08:35-PST
Date: 4 April 1983 14:12 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: buglisphack@sail
To: SAILBUGLISPHACK @ MIT-MC
I redirected all entries in our mailing lists file for buglisphack to
indirect through usc-ecl. You should start recieving bug-lisp (etc.) mail
again, and I should stop getting complaints from the mailer.
∂05-Apr-83 1911 George J. Carrette <GJC @ MIT-MC> LOOP macro expansions into LET
Received: from USC-ECL by SU-AI with NCP/FTP; 5 Apr 83 19:11:19 PST
Received: from MIT-MC by USC-ECL; Tue 5 Apr 83 19:04:39-PST
Date: 5 April 1983 22:05 EST
From: George J. Carrette <GJC @ MIT-MC>
Subject: LOOP macro expansions into LET
To: DCP @ SCRC-TENEX
cc: BUG-LISP @ MIT-MC, BUG-LOOP @ MIT-ML, GSB @ MIT-ML,
BSG @ SCRC-TENEX, bug-Lispm @ SCRC-TENEX
In-reply-to: Msg of 5 Apr 1983 19:23-EST from DCP at SCRC-TENEX
In PDP-10 maclisp, if you wanted to take up GSB's suggestion, you
could have LET and LET* in the interpreter autoload "LIBLSP;LETFEX FASL"
which is an implementation of LET optimized for the interpreter,
it defines 'em as FEXPRs. Not only is it fast and cons no extra
storage, it is about 1/6 the size of the macro let implementation,
and comes with a money-back guarantee..
∂05-Apr-83 2251 David C. Plummer <DCP@SCRC-TENEX> LOOP macro expansions
Received: from USC-ECL by SU-AI with NCP/FTP; 5 Apr 83 22:51:05 PST
Received: from MIT-MC by USC-ECL; Tue 5 Apr 83 22:49:55-PST
Received: from SCRC-MYSTIC by SCRC-TENEX with CHAOS; Wed 6-Apr-83 01:11:38-EST
Date: Wednesday, 6 April 1983, 01:07-EST
From: David C. Plummer <DCP@SCRC-TENEX>
Subject: LOOP macro expansions
To: BUG-lisp@MIT-MC, bug-Lispm@SCRC-TENEX, BUG-LOOP@MIT-ML
Cc: BSG@SCRC-TENEX, GSB@MIT-ML
In-reply-to: The message of 5 Apr 83 19:23-EST from DCP at SCRC-TENEX
Small warning to those who put my suggestion in their private versions
of LOOP: Be sure to also get the EVAL-WHEN at the beginning of the file
that sets up all the features/non-features. Failure to do this will,
among other things, cause collection to fail on the LispM. I just found
this out the hard way...
∂07-Apr-83 0125 Alan Bawden <ALAN @ MIT-MC>
Received: from USC-ECL by SU-AI with NCP/FTP; 7 Apr 83 01:25:01 PST
Received: from MIT-MC by USC-ECL; Thu 7 Apr 83 01:23:03-PST
Date: 7 April 1983 04:24 EST
From: Alan Bawden <ALAN @ MIT-MC>
To: BUG-LISP @ MIT-MC
Is LISP:LISP.SYMBOLS.2129 not the place I should expect to find the symbols
for MacLisp version 2129 currently running on OZ? They don't appear to be
correct.
∂07-Apr-83 0234 Alan Bawden <ALAN@MIT-OZ> I though we fixed this?
Received: from USC-ECL by SU-AI with NCP/FTP; 7 Apr 83 02:34:47 PST
Received: from MIT-MC by USC-ECL; Thu 7 Apr 83 02:30:24-PST
Date: Thu, 7 Apr 1983 05:17 EST
From: Alan Bawden <ALAN@MIT-OZ>
To: bug-lisp@MIT-OZ
Subject:I though we fixed this?
In my current lisp job on OZ:
(status ttysize)
(30 . -117)
Is this a "fixed in the source but not patched"?
∂08-Apr-83 2325 Alan Bawden <ALAN @ MIT-MC> Gratuitous optimization
Received: from USC-ECL by SU-AI with NCP/FTP; 8 Apr 83 23:25:33 PST
Received: from MIT-MC by USC-ECL; Fri 8 Apr 83 23:22:29-PST
Date: 9 April 1983 02:23 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Gratuitous optimization
To: BUG-COMPLR @ MIT-MC
I note that < has an optimizer that causes (< 1 x 8) to compile as one might
expect, while in the interpreter this is an error....
∂11-Apr-83 2051 Kent M. Pitman <KMP @ MIT-MC>
Received: from USC-ECL by SU-AI with NCP/FTP; 11 Apr 83 20:51:39 PST
Received: from MIT-MC by USC-ECL; Mon 11 Apr 83 18:08:52-PST
Date: 11 April 1983 21:08 EST
From: Kent M. Pitman <KMP @ MIT-MC>
To: bagley @ MIT-OZ
cc: BUG-LISP @ MIT-MC
Use ((LMLIB) LISPM) for now. Some of that stuff will become autoloading
in a Lisp release soon, I think.
∂11-Apr-83 2052 Kent M. Pitman <KMP @ MIT-MC>
Received: from USC-ECL by SU-AI with NCP/FTP; 11 Apr 83 20:52:02 PST
Received: from MIT-MC by USC-ECL; Mon 11 Apr 83 18:11:32-PST
Date: 11 April 1983 21:08 EST
From: Kent M. Pitman <KMP @ MIT-MC>
To: bagley @ MIT-OZ
cc: BUG-LISP @ MIT-MC
oops. i meant ((LIBLSP) LISPM).. sorry 'bout the confusion.
--kmp
∂11-Apr-83 2323 Pandora B. Berman <CENT @ MIT-ML> file migrated
Received: from USC-ECL by SU-AI with NCP/FTP; 11 Apr 83 23:23:42 PST
Received: from MIT-MC by USC-ECL; Mon 11 Apr 83 23:19:39-PST
Date: 12 April 1983 02:19 EST
From: Pandora B. Berman <CENT @ MIT-ML>
Subject: file migrated
To: bug-lisp @ MIT-OZ
dumper was trying to send this, but didn't know who to send it to. to
tell it, create a file called DIRECTORY.OWNER. which contains the name
of someone responsible for the dir; then dumper will send to that
person.
----------
Date: 11 Apr 1983 0538-EST
From: The Mailer Daemon <Mailer@MIT-OZ>
To: <TU77-MAN@MIT-OZ>
Subject: Message of 11-Apr-83 05:35:32
Message failed for the following:
LIBLSP@MIT-OZ: No such mailbox
------------
Date: 11-Apr-83 05:35:32
From: DUMPER
To: LIBLSP
Subject: Migrated files
The following files have been migrated:
PS:<LIBLSP>APROPOS.FASL.1
-------
∂13-Apr-83 2209 Dave Touretzky at CMU-CS-A CMU MacLisp broken
Received: from USC-ECL by SU-AI with NCP/FTP; 13 Apr 83 22:08:37 PST
Received: from MIT-MC by USC-ECL; Wed 13 Apr 83 22:05:22-PST
Date: 14 April 1983 0101-EST
From: Dave Touretzky at CMU-CS-A
To: bug-lisp at MIT-MC
Subject: CMU MacLisp broken
CC: Scott Fahlman <FAHLMAN at CMU-CS-C>,
Leonard Zubkoff <Zubkoff at CMU-CS-C>,
Neal Feinberg <feinberg at CMU-CS-C>, Richard Goldschmidt at CMU-CS-A
CMU recently, with no prior warning, changed the name of its primary TOPS-10
machine from CMU10A to CMUCSA. As a result, MacLisp no longer recognizes us
as a CMU site: (STATUS OPSYSTEM-TYPE) returns TOPS-10 instead of CMU. This
has in turn broken some of the code in the CMU MacLisp programming
environment.
I traced the problem to two lines of code a couple of screenfuls past the
label D10SET. The solution is to replace the string "CMU10" with the string
"CMUCS" where it appears on those two lines.
Would somebody like to make the change in the sources?
-- Dave Touretzky
∂17-Apr-83 1349 PASIEKA@MIT-OZ Pretty-Printer
Received: from USC-ECL by SU-AI with NCP/FTP; 17 Apr 83 13:49:22 PST
Received: from MIT-MC by USC-ECL; Sun 17 Apr 83 13:48:04-PST
Date: Sun, 17 Apr 1983 14:43 EST
From: PASIEKA@MIT-OZ
To: INFO-MACLISP@MIT-OZ
Subject: Pretty-Printer
I am trying to use the gobble code found in ksb on ml. In
trying to do this I have come up against the problem of transporting
the code to oz and making it work with the various hooks to pretty
print the objects created by the gobble functions. This has problems
when I try to move the code from the format directory on ml to oz.
Does anyone know if it is possible to transport this system to oz and
would they be willing to give me some help in doing so?
Thanks.
-- Mike
∂18-Apr-83 2004 WILLIS@MIT-ML
Received: from USC-ECL by SU-AI with NCP/FTP; 18 Apr 83 20:04:34 PST
Received: from MIT-MC by USC-ECL; Mon 18 Apr 83 20:04:22-PST
From: WILLIS@MIT-ML
Date: 04/18/83 23:04:55
WILLIS@MIT-ML 04/18/83 23:04:55
To: (BUG LISP) at MIT-ML
CC: WILLIS at MIT-ML
I have been trying for some time to print out text files on a printer
connected to my ADDS Viewpoint terminal.
At the cost of great pain and agony I managed (I think) to write a tiny
LISP program to send a file to the terminal without using the ITS PRINT
utility, since this does various things intended for the terminal which
foul up the printer output.
Imagine my shock and horror to find that (apparently) even the tyo subr
goes via CRTSTY, and therefore does annoying things like outputting
spaces (ASCII 32.) as cursor control characters.
Is there a LISP subr which sends absolutely nothing but the given ASCII
code to my modem? Alternatively, is there a system variable which I
can reset to make the system think (temporarily) that I have a totally
dumb terminal?
∂18-Apr-83 2117 Kent M. Pitman <kmp at MIT-MC> WILLIS@ML's TYO gripe
Received: from USC-ECL by SU-AI with NCP/FTP; 18 Apr 83 21:17:51 PST
Received: from MIT-MC by USC-ECL; Mon 18 Apr 83 21:17:05-PST
Date: Tuesday, 19 April 1983, 00:08-EST
From: Kent M. Pitman <kmp at MIT-MC>
Subject: WILLIS@ML's TYO gripe
To: bug-lisp at mc
I sent him a note suggesting he look into IMAGE mode I/O.
∂18-Apr-83 2129 Alan Bawden <ALAN @ MIT-MC> IMAGE mode IO
Received: from USC-ECL by SU-AI with NCP/FTP; 18 Apr 83 21:29:38 PST
Received: from MIT-MC by USC-ECL; Mon 18 Apr 83 21:25:43-PST
Date: 19 April 1983 00:17 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: IMAGE mode IO
To: WILLIS @ MIT-ML
cc: BUG-LISP @ MIT-ML
In-reply-to: Msg of 04/18/83 23:04:55 from WILLIS at MIT-ML
Well, its a real feature of ITS that the system always presents programs
with a virtual terminal so that they don't have to know the peculiarities
of the user's actual terminal. LISP is no exception to thiv@∞@≠∀≠M9$4)$4)4(4)94)%QL4)QQd%5¬≥∀%4)QQd4)→1%M@αode by doing:
(OPEN '|TTY:| '(OUT TTY IMAGE))
This form returns a file-object. Save that file-object and pass it to the
TYO function as a second argument. Then whatever you passed as the first
argument, should be sent directly to your device..
∂11-May-83 0928 @USC-ECL,@MIT-MC:SMATT@MIT-OZ LOOP CONTINUE STATEMENT
Received: from USC-ECL by SU-AI with TCP/SMTP; 11 May 83 09:26:56 PDT
Received: from MIT-MC by USC-ECL; Tue 10 May 83 23:04:47-PDT
Date: Wednesday, 11 May 1983, 01:58-EDT
From: Matt BenDaniel <SMATT@MIT-OZ>
Subject: LOOP CONTINUE STATEMENT
To: bug-LISPM@MIT-OZ, LISP-FORUM@MIT-OZ, dove@MIT-DSPG
In-reply-to: The message of 14 Apr 83 10:14-EST from Webster Dove <dove at MIT-DSPG>
I'd also be very interested in hearing answers to the following question:
Return-path: <dove@MIT-DSPG>
Date: Thursday, 14 April 1983, 10:14-EST
From: Webster Dove <dove at MIT-DSPG>
To: info-LISPM at MIT-OZ
Is there a way in (loop ...) to say
"go directly to the next iteration. Do not execute the remaining
clauses of the body"
Such statements typically are called "continue" or "next"
I have encountered many situations where such a statement would be
useful.
∂11-May-83 0931 @USC-ECL,@MIT-MC:MOON@SCRC-TENEX LOOP CONTINUE STATEMENT
Received: from USC-ECL by SU-AI with TCP/SMTP; 11 May 83 09:29:48 PDT
Received: from MIT-MC by USC-ECL; Wed 11 May 83 00:03:00-PDT
Date: Wednesday, 11 May 1983 02:43-EDT
From: MOON at SCRC-TENEX
To: Matt BenDaniel <SMATT at MIT-OZ>
Cc: bug-LISPM at MIT-OZ, dove at MIT-DSPG, LISP-FORUM at MIT-OZ
Subject: LOOP CONTINUE STATEMENT
In-reply-to: The message of 11 May 1983 01:58-EDT from Matt BenDaniel <SMATT@MIT-OZ>
Date: Wednesday, 11 May 1983, 01:58-EDT
From: Matt BenDaniel <SMATT@MIT-OZ>
I'd also be very interested in hearing answers to the following question:
Date: Thursday, 14 April 1983, 10:14-EST
From: Webster Dove <dove at MIT-DSPG>
Is there a way in (loop ...) to say
"go directly to the next iteration. Do not execute the remaining
clauses of the body"
Such statements typically are called "continue" or "next"
I have encountered many situations where such a statement would be
useful.
Date: Thursday, 14 April 1983 17:27-EST
From: MOON at SCRC-TENEX
In-reply-to: The message of 14 Apr 1983 10:14-EST from Webster Dove <dove at MIT-DSPG>
There isn't now. Normally one encloses the body in a conditional
(unfortunately, it can be painful to do this currently if the body
includes COLLECT statements). The main problem with having a continue
statement is that it may be unclear just what is regarded as "the body"
and what is regarded as "the iteration framework": If there is a WHILE
statement later in the LOOP than the CONTINUE, should it be skipped
or should it still be executed? And is the answer to this affected by
whether there is a DO after the WHILE?
∂11-May-83 1022 @USC-ECL,@MIT-MC:SMATT@MIT-OZ LOOP CONTINUE STATEMENT
Received: from USC-ECL by SU-AI with TCP/SMTP; 11 May 83 10:21:33 PDT
Received: from MIT-MC by USC-ECL; Wed 11 May 83 00:29:53-PDT
Date: Wednesday, 11 May 1983, 03:25-EDT
From: Matt BenDaniel <SMATT@MIT-OZ>
Subject: LOOP CONTINUE STATEMENT
To: MOON@SCRC-TENEX, SMATT@MIT-OZ
Cc: bug-LISPM@MIT-OZ, dove@MIT-DSPG, LISP-FORUM@MIT-OZ
In-reply-to: The message of 11 May 83 02:43-EDT from MOON at SCRC-TENEX
A CONTINUE statement should mean skipping executing any code lexically
after it on the current iteration. This could, of course, be a problem
in the following:
. . . (loop for x = 0 then (1+ x)
IF (> x 3)
CONTINUE
until (> x 7))
However, this is the problem of the coder. If there are other reasons
why implementing (or specifying) the function of a CONTINUE statement,
how about constraining the location of an IF-CONTINUE sequence in a
LOOP body in a manner similar to the IF-DO sequence, where iteration is
not allowed to follow body code. Also, what about a CONTINUE-NAMED
feature for NAMED loops?
∂14-May-83 1416 @USC-ECL,@MIT-MC:KMP@MIT-OZ <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 May 83 14:16:37 PDT
Received: from MIT-MC by USC-ECL; Sat 14 May 83 14:13:40-PDT
Date: Sat, 14 May 1983 17:01 EDT
From: KMP@MIT-OZ
To: BUG-LISP@MIT-OZ
cc: PHW@MIT-OZ
Subject: <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
PHW tried to use my TTY package (containing DO-WITH-TTY-ON,
DO-WITH-TTY-OFF, etc) and found it broken because the FASL file
was trying to INCLUDE LISP:SUBLOAD. The reason it was trying to
do this was to get around some hassle with SI:GEN-LOCAL-VARIABLE,
which JONL had patched the source to use in place of GENSYM.
The reason the INCLUDE happened at the wrong time was because
someone wrote (IF (STATUS FEATURE ITS) (INCLUDE ...) (INCLUDE ...))
instead of (INCLUDEF (IF ...)).
The macros in this file are the sort that other macros do not expand
into. They are the kind of thing which programs expand into and as
such, with the exception of a few cases of "#%", GENSYM is completely
reasonable and has no problems about it.
In any case, I have seen far too many bugs caused by the fact that
these things do not primitively autoload and I don't think it's worth
using either GENTEMP or SI:GEN-LOCAL-VARIABLE unless they become primitively
available. They are inappropriate for use in libraries which are not
maintained as an essential feature of the system until they are primitively
accessible.
I would appreciate if people would refrain from adding stupid little
"features" like this to my libraries without at least telling me that
they have done so and without checking that the "features" work. I tend
to check the software I release relatively carefully and this sort of
thing gives my software a bad name. In this case, the FASL file wouldn't
even LOAD so it's quite clear that no one had tested it.
I wrote OZ:PS:<LIBLSP>TTY.LSP.24 and compiled it. It seems to work fine.
Please report bugs.
By the way, this version also includes another macro called BIND-TTYINT
which allows a let-style syntax for binding TTYINT things. eg,
(BIND-TTYINT ((#↑B NIL) (#↑H #↑B)) ...body...)
binds ↑B to no interrupt and Backspace to work like ↑B for the invocation
of the BODY.
I'll copy this back to ITS later today in case anyone finds it easier to
pick up the new versions from there than from here.
--kmp
∂14-May-83 1632 @USC-ECL:KMP@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 May 83 16:32:17 PDT
Received: from MIT-MC by USC-ECL; Sat 14 May 83 15:19:58-PDT
Date: 14 May 1983 18:17 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: INFO-MACLISP @ MIT-MC
I added a macro called BIND-TTYINT to the TTY package on LIBLSP.
It binds the TTYINT status of one or more characters within a given
dynamic scope. Sample calling sequence is
(BIND-TTYINT ((#↑B NIL) ;disable control-B
(#↑↑ #↑G) ;make control-↑ like control-G
(#↑H #'FOO)) ;make control-H (Backspace) handled by function FOO
...body...)
To get these fixes outside of MIT, Lisp maintainers need to pick up
version 24 of ((LIBLSP) TTY).
--kmp
∂15-May-83 0920 @USC-ECL,@MIT-MC:GJC@MIT-MC <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
Received: from USC-ECL by SU-AI with TCP/SMTP; 15 May 83 09:11:15 PDT
Received: from MIT-MC by USC-ECL; Sun 15 May 83 09:06:28-PDT
Date: 15 May 1983 12:02 EDT
From: George J. Carrette <GJC @ MIT-MC>
Subject: <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
To: KMP @ MIT-OZ
cc: BUG-LISP @ MIT-OZ, PHW @ MIT-OZ
In-reply-to: Msg of Sat 14 May 1983 17:01 EDT from KMP at MIT-OZ
I could have sworn that I diked out the SUBLOAD and SI:GENTEMP stuff
from TTY a while ago. Indeed, check out LIBDOC;TTY 19, which was
written in NOV '82. At least the FASL for this was moved to OZ also,
when I found I got screwed by missing autoload files. Evidently the OZ
version was further hacked later on by someone else, reintroducing the
lossage. Blame me for not moving the source to OZ also.
N.B. All those who would hack Maclisp on OZ: The sources to Maclisp have
not ever been considered to be on OZ. The software was installed by
"helpful" outsiders before responsible local maclisp hackers could act.
Since then it has been fun to watch. Kent, if it weren't for people like
you fixing up things maybe we could have the total collapse that would
lead to a fresh start though?
-gjc
∂26-May-83 2214 @USC-ECL,@MIT-MC:ALAN@MIT-OZ Yuch!
Received: from USC-ECL by SU-AI with TCP/SMTP; 26 May 83 22:14:27 PDT
Received: from MIT-MC by USC-ECL; Thu 26 May 83 22:11:40-PDT
Date: Fri, 27 May 1983 01:08 EDT
From: Alan Bawden <ALAN@MIT-OZ>
To: bug-lisp@MIT-OZ
Subject:Yuch!
I just discovered that the setting of the MAKHUNK switch controls TWO
things at once. Setting it to T makes (makhunk 2) return a hunk (which I
like), and it also makes '(1 . 2 .) return a hunk (which I think sucks, I
would much prefer to get a dot context error). Yuch!
∂04-Jun-83 1636 @USC-ECL,@MIT-MC:SAZ@MIT-OZ binding 't to other things (like nil)
Received: from USC-ECL by SU-AI with TCP/SMTP; 4 Jun 83 16:36:46 PDT
Received: from MIT-MC by USC-ECL; Sat 4 Jun 83 16:35:45-PDT
Date: Saturday, 4 June 1983, 19:32-EDT
From: David M. J. Saslav <SAZ@MIT-OZ>
Subject: binding 't to other things (like nil)
To: bug-lisp@MIT-OZ
I don't think it's a good idea to be able to say (setq 't ni), since this makes forms like
(cond (t 45) (nil 50) ((print "me") 100)) return:
ME
100
∂14-Jun-83 0306 @USC-ECL,@MIT-MC:CENT@MIT-ML files migrated on oz
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jun 83 03:06:43 PDT
Received: from MIT-MC by USC-ECL; Tue 14 Jun 83 03:02:45-PDT
From: CENT@MIT-ML
Date: 06/14/83 06:00:30
Subject: files migrated on oz
CENT@MIT-ML 06/14/83 06:00:30 Re: files migrated on oz
To: (BUG LISP) at MIT-ML
if there is someone locally responsible for worrying about this sort
of thing, please create a DIRECTORY.OWNER file on this dir so i
don't have to bother everyone when files get reaped.
----------
Date: 14-Jun-83 02:46:24
From: Dumper <DUMPER@MIT-OZ>
Reply-to: File-Retrieve <FILE-R@MIT-OZ>
To: BUG-BACKUPERS
Subject: Migrated files
The following files have been migrated:
PS:<MACLISP>6003.LISP.4
PS:<MACLISP>LISP.EXE.2131
PS:<MACLISP>TTY.FASL.18
∂14-Jun-83 2302 @USC-ECL,@MIT-MC:VaughanW@HI-MULTICS Call For Papers
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jun 83 23:02:05 PDT
Received: from MIT-MC by USC-ECL; Tue 14 Jun 83 22:57:31-PDT
Redistributed-Date: 14 June 1983 22:27 mst
Redistributed-By: VaughanW.REFLECS at HI-MULTICS
Redistributed-To: info-ada at MIT-MC, editor-people at SU-SCORE,
lisp-forum at MIT-MC
Date: 27 May 1983 19:08 mst
From: VaughanW at HI-MULTICS (Bill Vaughan)
Subject: Call For Papers
To: HUMAN-NETS at RUTGERS
cc: sf-lovers at MIT-AI, info-micro at MIT-MC
Last year at this time I put the Call for Papers for the PC3 conference out to
these mailing lists and bulletin boards. We seemed to get a good response, so
here it is again. Notice that this year's theme is a little different.
Further note that we are formally refereeing papers this year.
If anyone out there is interested in refereeing, please send me a note.
---------------
Third annual Phoenix Conference on Computers and Communications
CALL FOR PAPERS
Theme: THE CHALLENGE OF CHANGE - Applying Evolving Technology.
The conference seeks to attract quality papers with emphasis on the following
areas:
APPLICATIONS -- Office automation; Personal Computers; Distributed systems;
Local/Wide Area Networks; Robotics, CAD/CAM; Knowledge-based systems; unusual
applications.
TECHNOLOGY -- New architectures; 5th generation & LISP machines; New
microprocessor hardware; Software engineering; Cellular mobile radio;
Integrated speech/data networks; Voice data systems; ICs and devices.
QUALITY -- Reliability/Availiability/Serviceability; Human engineering;
Performance measurement; Design methodologies; Testing/validation/proof
techniques.
Authors of papers (3000-5000 words) or short papers (1000-1500 words) are to
submit abstracts (300 words max.) with authors' names, addresses, and
telephone numbers. Proposals for panels or special sessions are to contain
sufficient detail to explain the presentation. 5 copies of the completed
paper must be submitted, with authors' names and affiliations on a separate
sheet of paper, in order to provide for blind refereeing.
Abstracts and proposals due: August 1
Full papers due: September 15
Notification of Acceptance: November 15
Conference Dates: March 19-21, 1984
Address the abstract and all other replies to:
Susan C. Brewer
Honeywell LCPD, MS Z22
PO Box 8000 N
Phoenix AZ 85066
----------------
Or you can send stuff to me, Bill Vaughan (VaughanW @ HI-Multics) and I will
make sure Susan gets it.
∂16-Jun-83 1714 @USC-ECL:ALAN@MIT-MC New MacLisp now installed on MC.
Received: from USC-ECL by SU-AI with TCP/SMTP; 16 Jun 83 17:13:19 PDT
Received: from MIT-MC by USC-ECL; Thu 16 Jun 83 17:08:16-PDT
Date: 16 June 1983 20:05 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: New MacLisp now installed on MC.
To: BUG-LISP @ MIT-MC, INFO-MACLISP @ MIT-MC, (*MSG *MC) @ MIT-MC
I have just installed a new MacLisp (version 2138) on MC forged from the
latest sources. This corresponds almost exactly to the XLISP that has been
available on MC for the last month or so. Since most of the changes to the
sources since the last MacLisp were made (over a year ago) had to do with IO
on 20X, there is little to watch out for. A matching COMPLR has been
installed as well, along with a MACLISP and a SHARABLE built on top of it.
The previous versions of LISP and COMPLR have been renamed to OLISP and
OCOMPLR.
People who maintain dumped systems are encouraged to update their entries
in LISP;LOCK >. I garbage collected quite a few entries myself, and
several dumps are going to disappear from disk soon unless someone speaks
up for them.
∂29-Jun-83 1119 @USC-ECL:CFFK@MIT-MC Cursor positioning with Tops-20 lisp (in Macsyma on XX)
Received: from USC-ECL by SU-AI with TCP/SMTP; 29 Jun 83 11:19:09 PDT
Received: from MIT-MC by USC-ECL; Wed 29 Jun 83 09:40:38-PDT
Date: 29 June 1983 12:38 EDT
From: Charles F. F. Karney <CFFK @ MIT-MC>
Subject: Cursor positioning with Tops-20 lisp (in Macsyma on XX)
To: BUG-LISP @ MIT-MC
cc: JPG @ MIT-MC
If I perform the following code:
(setq tt (open '|tty:| '(tty out image single)))
(defun ttt ()
(mapcar (function (lambda (x) (+tyo x tt)))
'(143. 20. 20. 65. 66. 67. 143. 0. 0.))
(tyi))
(ttt)<space>
Then 'ABC' gets written out at position 20,20 and the
cursror homes. However following this <newlines> don't get
generated. E.g. t<space> ==> T (on the same line).
(cursorpos 'top) clears this condition.
This works OK in ITS..
∂04-Jul-83 1523 @USC-ECL:JGA@MIT-MC a question of interrupts (I guess)
Received: from USC-ECL by SU-AI with TCP/SMTP; 4 Jul 83 15:23:17 PDT
Received: from MIT-MC by USC-ECL; Mon 4 Jul 83 15:18:34-PDT
Date: 4 July 1983 18:17 EDT
From: John G. Aspinall <JGA @ MIT-MC>
Subject: a question of interrupts (I guess)
To: BUG-LISP @ MIT-MC
cc: JGA @ MIT-MC
I have a problem that seems like some sort of synchronization
thing, but I don't really understand it.
The following function queries a Tektronix terminal for its
joystick position.
(defun tek-get-ginput ()
(+tyo #\ALT graphic-output)
(+tyo #\TEK-GINMODE graphic-output)
(prog1 (do-with-tty-off
(list (tyi)
(+ (lsh (logand (tyi) #o37) 5) (logand (tyi) #o37))
(+ (lsh (logand (tyi) #o37) 5) (logand (tyi) #o37))))
(tyi)))
Graphic-output is a output stream, open in image mode, to the tty.
The two-character sequence <alt> <ctrl-z> (#\tek-ginmode is defined as
#o32) puts the Tek in GIN (Graphic INput) mode. The regular cursor
disappears, and is replaced with an arrow. The user points this at
wherever, and hits any key. The Tek transmits a 6 character sequence
- the key typed is first, then four (non-control) characters
containing the coordinates (encoded obviously above), then a <cr>.
The <cr>'s job is to return the Tek to it's previous mode (not GIN
mode) so it ought to be echoed, the other chars probably shouldn't be
echoed, hence the code above.
Now the problem. I put this in a real simple command loop to trace a
pattern on the screen - m:move, d:draw, etc. This thing returns a lisp
form that can be evaluated for the pattern again.
(defun trace ()
(do ((com (tek-get-ginput) (tek-get-ginput))
(form nil))
((or (= (car com) #/q) (= (car com) #/Q)) (cons 'progn (nreverse form)))
(caseq (car com)
((#\FF)
(graphout (page)
(do ((form (reverse form) (cdr form)))
((null form))
(eval (car form)))))
((#/m #/M)
(push (rplaca com 'move) form))
((#/d #/D)
(push (rplaca com 'draw) form))
((#\RUBOUT)
(pop form)))))
This works fine, IF I TYPE SLOWLY ENOUGH. (This, on a 1200 baud
Vadic, MC lightly loaded.) On the other hand, two keystroke commands
within (I would guess) 0.5 second of each other, put it in a state
where it looks as if something's out of synch. Several keystrokes
later, it sometimes returns to normal, having missed all those
commands, but I can't reproduce that reliably.
All suggestions welcome - and thanks in advance.
∂15-Jul-83 1751 @USC-ECL:ALAN@MIT-MC Mustn't call UINT0 from within a PI server
Received: from USC-ECL by SU-AI with TCP/SMTP; 15 Jul 83 17:51:15 PDT
Received: from MIT-MC by USC-ECL; Fri 15 Jul 83 17:48:26-PDT
Date: 15 July 1983 20:46 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Mustn't call UINT0 from within a PI server
To: BUG-LISP @ MIT-MC, MOON @ MIT-MC, ELLEN @ MIT-MC
Date: 15 July 1983 01:46 EDT
From: V. Ellen Golden <ELLEN>
To: ALAN
Re: BUG LISP????
I have seen this twice now, but the people usually started up
a new MACSYMA. Dave MOON helped RGA to save his, and he (MOON)
thought it was a Lisp problem, so it might be related to the new
lisp.... I send it to you (This is the one MOON fixed...).
Date: 12 July 1983 16:06 EDT
From: V. Ellen Golden <ELLEN @ MIT-MC>
Date: 12 July 1983 12:37 EDT
From: Richard Gregory-Allen <RGA @ MIT-MC>
Here I am in another fix. I was running a Macsyma and had ↑Z'd out to
play around in the editor. When I tried to $P back into my job, I got
the following message;
ERROR; (ATTY;) 65063>>CAME 6,1642 6/ -41,,1642 1642/ -31,,1652
and I'm back at DDT. (I don't remember if the (ATTY;) was
there before I disowned it the first time, I don't think so
though.)
I've got quite a bit of time invested in the session so I'd really love
to be able to rescue it. I've seen this condition before (with
less invested)
though only since this latest version (304) of Macsyma has
been installed. I've disowned the job (jobname is A) in hopes
that you can somehow fix it.
--------------
This error is somehow associated with the "tty handler" and MACSYMA getting
control of the "tty". In general it means that the job is "broken", but
I was able to get Dave MOON to look at it and he managed to get rid
of the interrupt and rescue the MACSYMA. It is now sitting loose in the
system as ELLEN A. To reown it and save out what you want you type
:ujob ellen a
Good luck!
The code near the .LOSE in question:
MOVE T,[-LINTPDL,,INTPDL] ;MUSTN'T CALL UINT0 FROM
CAME T,INTPDL ; WITHIN A PI SERVER
.LOSE
I guess I would like to know what was on the interrupt PDL when this
happens. (Perhaps Moon will tell me.) I can't seem to reproduce this
myself, but it is a little vague just what this guy was doing. (He speaks
of "disowning" as if he thinks that that is what ↑Z does, or perhaps he
isn't telling the whose story.) Next time it happens perhaps someone will
dump the remains on the CRASH; directory for autopsy? (Although I guess
that might not save all the necessary state for something
interrupt-driven.)
In the meantime I guess It's time to learn about how interrupts work.
Perhaps anyone on bug-lisp who might have an idea why any changes made in
the last year should change anything interrupt related (I just examined all
of the recent changes, and I don't see any obvious candidates) should speak
up.
∂15-Jul-83 1927 @USC-ECL,@MIT-MC:GSB@MIT-ML .lose because of intpdl
Received: from USC-ECL by SU-AI with TCP/SMTP; 15 Jul 83 19:26:52 PDT
Received: from MIT-MC by USC-ECL; Fri 15 Jul 83 19:21:48-PDT
From: GSB@MIT-ML
Date: 07/15/83 22:17:45
Subject: .lose because of intpdl
GSB@MIT-ML 07/15/83 22:17:45 Re: .lose because of intpdl
To: ALAN at MIT-ML
CC: (BUG lisp) at MIT-MC
I think i have seen this before, but am not absolutely certain. UINT0B
familiar; this may not be new.
∂16-Jul-83 2233 @USC-ECL:JPG@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 16 Jul 83 22:11:13 PDT
Received: from MIT-MC by USC-ECL; Sat 16 Jul 83 22:07:11-PDT
Date: 17 July 1983 01:05 EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
To: MMMM @ MIT-MC
cc: ELLEN @ MIT-MC, JPG @ MIT-MC, BUG-LISP @ MIT-MC
MMMM@MIT-MC 07/16/83 23:55:43
What does the error code "65063>>CAME 6,1642" mean? If I do get this
error how do i continue working in macsyma. This error takes me to DDT
and :job followed by :continue does not get me back to macsyma.
It appears to be caused by a bug in the tty interrupt routines in the
Lisp that Macsyma is in. I do not know how you continue working with that
Macsyma. (I have not seen this happen myself, but I have heard of its
happening.) If this happens to you again, the best thing you can do is
disown that Macsyma and send a note to BUG-LISP and/or to MACSYM so that
a Lisp expert can study the broken Macsyma in the hopes of figuring out
just what is causing this.
∂19-Jul-83 1917 @USC-ECL,@MIT-MC:BEN@MIT-ML Bug in DO when compiled.
Received: from USC-ECL by SU-AI with TCP/SMTP; 19 Jul 83 19:16:56 PDT
Received: from MIT-MC by USC-ECL; Tue 19 Jul 83 12:36:24-PDT
From: BEN@MIT-ML
Date: 07/19/83 15:28:52
Subject: Bug in DO when compiled.
BEN@MIT-ML 07/19/83 15:28:52 Re: Bug in DO when compiled.
To: (BUG LISP) at MIT-ML
CC: BEN at MIT-ML
A simple iteration using DO, with no global variables or anything
funny, works correctly when interpreted, fails when compiled.
The simple version of the bug is in BEN;DO←BUG > and DO←BUG FASL.
The problem is that the update value for the first DO variable D
behaves as if it had the same expression as the second variable D1.
Even if this cannot be fixed in the visible future, it would be
very valuable to know the nature and extent of this bug.
∂19-Jul-83 1917 @USC-ECL:KMP@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 19 Jul 83 19:17:14 PDT
Received: from MIT-MC by USC-ECL; Tue 19 Jul 83 12:58:44-PDT
Date: 19 July 1983 15:50 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: BEN @ MIT-ML
cc: BUG-LISP @ MIT-MC
You're right.
(defun f (a b)
(do ((d a d1)
(d1 b (+ d d1)))
((> d 200.))
(print (list 'D= d 'D1= d1))))
compiles wrong. I believe this is a known bug related to number compilation.
I have heard it explained but don't recall the explanation so can't tell you
how to predict it. Perhaps someone else on this list will volunteer it.
In any case, either of
(defun f (a b)
(declare (fixnum a b))
(do ((d a d1)
(d1 b (+ d d1)))
((> d 200.))
(declare (fixnum d d1))
(print (list 'D= d 'D1= d1))))
or
(defun f (a b)
(do ((d a d1)
(d1 b (plus d d1)))
((greaterp d 200.))
(print (list 'd= d 'd1= d1))))
will work for you. Hope this is at least somewhat helpful. Probably you want
the former; the latter is just there for contrast.
∂20-Jul-83 2228 @USC-ECL:ALAN@MIT-MC More bits.
Received: from USC-ECL by SU-AI with TCP/SMTP; 20 Jul 83 22:27:50 PDT
Received: from MIT-MC by USC-ECL; Wed 20 Jul 83 22:27:27-PDT
Date: 21 July 1983 01:18 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: More bits.
To: MMMM @ MIT-MC, JPG @ MIT-MC, ELLEN @ MIT-MC, BUG-LISP @ MIT-MC
Date: 20 July 1983 21:10 EDT
From: Moses Minta <MMMM>
To: BUG-LI
Here is the error which is suspected to be caused by a bug in
tty(lisp?). I was advised to disown the job and send you this message.
Will appreciate any help in solving this mystery. Thanks.
Thanks! Now we have an example to study. I dumped this lisp in
CRASH;LISP TTYRET and recorded the user variables in ALAN;TTYRET VARS if
anyone else would like to take a look at this.
Despite the fact that when this bug usually happens it is a %PJATY
interrupt that is already sitting on INTPDL, in THIS case it seems to be an
interrupt on the TTY: input channel! The thing that all instances do have
in common, however, is that an UNWIND-PROTECT was interrupted out of (look
at the gubble at the top of the stack). [I guess "TTYRET" wasn't a good
name in light of this.]
I still don't understand what is going on here though.
BTW, I have had no trouble $Ging a Macsyma that dies in this way.
∂05-Aug-83 1143 @USC-ECL,@MIT-MC:JUDY@MIT-OZ problem with setting the status of the random function
Received: from USC-ECL by SU-AI with TCP/SMTP; 5 Aug 83 11:43:40 PDT
Received: from MIT-MC by USC-ECL; Fri 5 Aug 83 11:41:20-PDT
Date: Fri, 5 Aug 1983 14:33 EDT
From: JUDY@MIT-OZ
To: bug-maclisp@MIT-OZ
cc: judy@MIT-OZ
Subject: problem with setting the status of the random function
Depending upon the current random seed, Maclisp sometimes gives an
error message of "bad argument" for the call
(sstatus random (status random))
and similarly for something like
(setq foo (status random))
(sstatus random foo)
In particular this will happen (to me at least) after random is called
34 (base 10) times, 70 times, 105 times, 141 times, 176 times, 212
times, etc.
After random has been called 34 times (starting with the initial seed)
(status random) returns (0 36 26091955856 ...).
After 70 times (status random) returns (35 0 26091955856 ...)
105 (0 36 22609952497 ...)
141 (35 0 22609952497 ...)
176 (0 36 -14927067643 ...)
212 (35 0 -14927067643 ...)
If you will notice, 70 is 36 away from 34, 105 is 35 away from 70, 141
is 36 away from 105, etc.
Judy
∂05-Aug-83 1224 @USC-ECL:KMP@MIT-MC Judy's RANDOM bug
Received: from USC-ECL by SU-AI with TCP/SMTP; 5 Aug 83 12:24:43 PDT
Received: from MIT-MC by USC-ECL; Fri 5 Aug 83 12:24:12-PDT
Date: 5 August 1983 15:19 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: Judy's RANDOM bug
To: BUG-MACLISP @ MIT-MC
I put a function RANDOM-TESTER in the file MC:LSPSRC;RNDTST which will
cause Judy's bug to happen while also printing other useful debugging
info. If/when a fix is made, you might use this function to test the
fix.
As a hunch, I tried just patching SSRAN6+2 to use JUMPL instead of JUMPLE
(in Lisp 2138 on ITS) and this makes my RANDOM-TESTER function happy.
That of course doesn't mean it's the right fix, but it does suggest
that the error checking is probably just overly paranoid since presumably
something coming out of (STATUS RANDOM) has to be a valid input to
(SSTATUS RANDOM).
∂06-Aug-83 0133 @USC-ECL:ALAN@MIT-MC (sstatus random (status random))
Received: from USC-ECL by SU-AI with TCP/SMTP; 6 Aug 83 01:32:59 PDT
Received: from MIT-MC by USC-ECL; Fri 5 Aug 83 19:13:54-PDT
Date: 5 August 1983 22:06 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: (sstatus random (status random))
To: KMP @ MIT-MC, JUDY @ MIT-OZ
cc: BUG-MACLISP @ MIT-MC
In-reply-to: Msg of Fri 5 Aug 1983 14:33 EDT from JUDY at MIT-OZ
Date: Fri, 5 Aug 1983 14:33 EDT
From: JUDY at MIT-OZ
Depending upon the current random seed, Maclisp sometimes gives an
error message of "bad argument" for the call
(sstatus random (status random))
Date: 5 August 1983 15:19 EDT
From: Kent M. Pitman <KMP>
As a hunch, I tried just patching SSRAN6+2 to use JUMPL instead of JUMPLE
(in Lisp 2138 on ITS) and this makes my RANDOM-TESTER function happy.
That of course doesn't mean it's the right fix, but it does suggest
that the error checking is probably just overly paranoid since presumably
something coming out of (STATUS RANDOM) has to be a valid input to
(SSTATUS RANDOM).
Thank you KMP, you are absolutely correct. Fixed in the source. I also
fixed the check at SSRAN6+3 which was a little too liberal about what it
accepted.
[I must look up the reference for this random number generator. It seems
to be different from the LispMachine version in that it steps its pair of
pointers in the opposite direction. I suspect this makes a difference in
the randomness of the result. Of course I can't fix it if people are
depending on (sstatus random 17) doing the same thing next year as
last...]
∂23-Aug-83 1147 @USC-ECL,@MIT-MC:PADGET@UTAH-20 function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 23 Aug 83 11:47:32 PDT
Received: from MIT-MC by USC-ECL; Tue 23 Aug 83 11:39:14-PDT
Date: 23 Aug 1983 1135-MDT
From: Julian Padget <PADGET@UTAH-20>
Subject: function cells
To: lisp-forum@MIT-MC
cc: Padget@UTAH-20
I am doing a little bit of historical digging on LISP, and I would like
to know who claims responsibility for the invention of the function cell
which is common to so many LISP implementations. Further I would be interested
to hear a justification for both its invention and retention.
--Julian Padget (Padget@Utah-20).
-------
∂23-Aug-83 1424 @USC-ECL,@MIT-MC:Deutsch.PA@PARC-MAXC Re: function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 23 Aug 83 14:23:46 PDT
Received: from MIT-MC by USC-ECL; Tue 23 Aug 83 14:22:11-PDT
Date: Tue, 23 Aug 83 14:13 PDT
From: Deutsch.PA@PARC-MAXC.ARPA
Subject: Re: function cells
In-reply-to: "PADGET@UTAH-20.ARPA's message of 23 Aug 83 11:35 MDT"
To: Julian Padget <PADGET@UTAH-20.ARPA>
cc: lisp-forum@MIT-MC.ARPA, Bobrow.PA@PARC-MAXC.ARPA,
Teitelman.PA@PARC-MAXC.ARPA
Lisp 1.5 stored function definitions on the property list. To my
knowledge, the first Lisp that used an independent function cell was the
PDP-1 implementation of BBN-Lisp, the precursor of Interlisp. Dan
Bobrow may be able to confirm or add details. This would have been
around 1965. He and I were the principal architects of this system; I
would trust his word about who invented what. You may find other
interesting historical information in the Information International Inc.
Lisp system book, edited by Edmund C. Berkeley and also published
sometime around 1965. It doesn't describe BBN-Lisp, but it describes
some other systems, and one of them may have function cells -- I don't
really remember.
I don't know what alternatives you want a justification with respect to.
The changeover from property list representation was primarily for
efficiency. The distinction between "function context" and "variable
context" for interpreting names was a bad idea inherited from Lisp 1.5:
it was retained for a very long time because doing free variable lookups
for every function name (which are normally only bound at the top level)
would have been atrociously slow. It was only with the invention of
shallow binding that people started to look seriously at re-merging
function and variable binding.
∂30-Aug-83 1738 @USC-ECL,@MIT-MC:Bobrow.PA@PARC-MAXC Re: function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 30 Aug 83 14:35:39 PDT
Received: from MIT-MC by USC-ECL; Tue 30 Aug 83 14:30:54-PDT
Date: Tue, 30 Aug 83 13:54 PDT
From: Bobrow.PA@PARC-MAXC.ARPA
Subject: Re: function cells
In-reply-to: "Deutsch's message of Tue, 23 Aug 83 14:13 PDT"
To: Julian Padget <PADGET@UTAH-20.ARPA>
cc: Deutsch.PA@PARC-MAXC.ARPA, lisp-forum@MIT-MC.ARPA,
Bobrow.PA@PARC-MAXC.ARPA, Teitelman.PA@PARC-MAXC.ARPA
I must admit that it was my idea of having separate function cells,
value cells, pname cells, and property lists for Lisp atoms in BBN-Lisp.
I am a believer in separating out mechanisms when there are distinct
differences in function. I think lookup of functions is semantically
different than lookup of variables. The time scale for which bindings
are applicable for variables and fn definitions are applicable are quite
different different in the usual case.
∂30-Aug-83 2109 @USC-ECL:GJC@MIT-MC Function cells.
Received: from USC-ECL by SU-AI with TCP/SMTP; 30 Aug 83 21:09:31 PDT
Received: from MIT-MC by USC-ECL; Tue 30 Aug 83 21:04:04-PDT
Date: 30 August 1983 23:58 EDT
From: George J. Carrette <GJC @ MIT-MC>
Subject: Function cells.
To: LISP-FORUM @ MIT-MC
I would credit JONL with introducing what is effectively the
function-cell functionality to Maclisp. Even though the internals
of the function calling mechanism in maclisp uses various properties,
EXPR, FEXPR, LSUBR, SUBR, FSUBR, and also various function cells with
the UUOLINK mechanism, the user only need be aware of the existence of
DEFUN. Here is some old lisp mail on the topic:
3/1/69 JONL
THE CURRENT VERSION OF LISP, "LISP 102", HAS
THE FOLLOWING AS-YET UNDOCUMENTED FEATURES:
1)"DEFUN" IS AN FSUBR USED TO DEFINE
FUNCTIONS. EXAMPLES ARE
(DEFUN ONECONS (X) (CONS 1 X))
WHICH IS EQUIVALENT TO
(DEFPROP ONECONS
(LAMBDA (X) (CONS 1 X)
EXPR)
THE NOVEL FEATURE OF "DEFUN" IS THAT ONE NEED
NOT BE SO CONCERNED WITH BALANCING
PARENTHESES AT THE VERY END OF THE FUNCTION
DEFINITION. ALSO, THE "LAMBDA" NEED NOT BE
DIRECTLY INSERTED.
Of course, the time this note was written none of the hairier
specialized calling mechanisms had been added to maclisp.
-gjc
∂01-Sep-83 0534 @USC-ECL,@MIT-MC:TIM@MIT-OZ Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 1 Sep 83 05:34:20 PDT
Received: from MIT-MC by USC-ECL; Thu 1 Sep 83 05:34:10-PDT
Date: Thu, 1 Sep 1983 07:37 EDT
Message-ID: <[MIT-OZ].TIM. 1-Sep-83 07:37:32>
From: TIM@MIT-OZ
To: Bobrow.PA@PARC-MAXC.ARPA
Cc: Deutsch.PA@PARC-MAXC.ARPA, lisp-forum@MIT-MC.ARPA,
Julian Padget <PADGET@UTAH-20.ARPA>, Teitelman.PA@PARC-MAXC.ARPA
Subject: Function cells
In-reply-to: Msg of 30 Aug 1983 16:54-EDT from Bobrow.PA at PARC-MAXC.ARPA
For the "usual case" it is perfectly reasonable to have separate
function and value cells--I make use of that feature all the time.
But the situation changes when you start to pass functions around in
value cells. The awkward convention of specifying a function call by
(FUNCALL fun arg1 arg2 ...) ;where the function is found in the
;value cell of FUN
rather than
(fun arg1 arg2 ...) ;in the usual case
is perpetuated by having both a function cell and a value cell. In
languages which do not adopt this convention (such as Gerry Sussman
and Guy Steele's Scheme) it is possible to use the latter form in
every case, even when FUN has been passed as an argument. Thus
(define (foo fn a b) ;(The slight difference in the syntax
(fn (* 2 a) b)) ;of FOO's function spec is incidental)
replaces
(defun foo (fn a b)
(funcall fn (* 2 a) b))
I realize that the deep binding scheme in early Lisp implementations
made it necessary to have a separate mechanism for fast function
lookup, and that the namespace limitation of dynamic scoping makes
having a function context and a variable context handy, but I do not
think that the function/value dichotomy should continue into the
lexically scoped Common Lisp. In the case where a variable contains a
function (in its value cell) I see little semantic distinction between
the lookup of variables and functions. In this respect, I fail to see
your point about "separating out mechanisms." I see it justifiable
only for efficiency reasons and for coping with a limited namespace.
Tim McNerney
∂01-Sep-83 1454 @USC-ECL,@MIT-MC:Bobrow.PA@PARC-MAXC Re: Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 1 Sep 83 14:54:01 PDT
Received: from MIT-MC by USC-ECL; Thu 1 Sep 83 14:51:40-PDT
Date: Thu, 1 Sep 83 14:30 PDT
From: Bobrow.PA@PARC-MAXC.ARPA
Subject: Re: Function cells
In-reply-to: <[MIT-OZ].TIM. 1-Sep-83 07:37:32>
To: TIM%MIT-OZ@MIT-MC.ARPA
cc: Bobrow.PA@PARC-MAXC.ARPA, Deutsch.PA@PARC-MAXC.ARPA,
lisp-forum@MIT-MC.ARPA, Julian Padget <PADGET@UTAH-20.ARPA>,
Teitelman.PA@PARC-MAXC.ARPA
Tim,
There is a difference in meaning between:
(fun x y) and (FUNCALL fun x y).
In the former case, one expects the meaning of fun to be independent of
the context of the call. In the latter, to be dependent of parameters
passed in to the environment. One can take the point of view that one
doesn't want to distinguish these cases, but I maintain that the code is
clearer when you do make the distinction for the call. Similarly, I
have seen proposals for doing object oriented programming by having the
function name evaluated in the context of the first argument to the
function (which would in fact be a closure on some functions and
variables). I object to that as well.
So for me the question is not about efficiency and limitation of name
space, but of what distinctions you want to make apparent at a call.
danny bobrow
∂01-Sep-83 1549 @USC-ECL,@MIT-MC:BENSON@SPA-NIMBUS Re: Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 1 Sep 83 15:49:35 PDT
Received: from MIT-MC by USC-ECL; Thu 1 Sep 83 15:41:07-PDT
Received: from SPA-Nimbus by SPA-Nimbus with CHAOS; Thu 1-Sep-83 15:36:05-PDT
Date: Thursday, 1 September 1983, 15:35-PDT
From: Eric Benson <BENSON at SPA-Nimbus>
Subject: Re: Function cells
To: Bobrow.PA at PARC-MAXC.ARPA, TIM%MIT-OZ at MIT-MC.ARPA
Cc: Deutsch.PA at PARC-MAXC.ARPA, lisp-forum at MIT-MC.ARPA,
Julian Padget <PADGET at UTAH-20.ARPA>,
Teitelman.PA at PARC-MAXC.ARPA
In-reply-to: The message of 1 Sep 83 14:30-PDT from Bobrow.PA at PARC-MAXC.ARPA
Date: Thu, 1 Sep 83 14:30 PDT
From: Bobrow.PA@PARC-MAXC.ARPA
Tim,
There is a difference in meaning between:
(fun x y) and (FUNCALL fun x y).
In the former case, one expects the meaning of fun to be independent of
the context of the call. In the latter, to be dependent of parameters
passed in to the environment. One can take the point of view that one
doesn't want to distinguish these cases, but I maintain that the code is
clearer when you do make the distinction for the call. Similarly, I
have seen proposals for doing object oriented programming by having the
function name evaluated in the context of the first argument to the
function (which would in fact be a closure on some functions and
variables). I object to that as well.
So for me the question is not about efficiency and limitation of name
space, but of what distinctions you want to make apparent at a call.
danny bobrow
By this reasoning you must object to the Common Lisp special forms
LABELS and FLET, which define lexically scoped functions. With the
inclusion of these, function name evaluation is no longer independent of
context. It is only dependent on the static context, however; there is
no dynamic binding of function names in Common Lisp. Is it only
dependence on dynamic context you object to, or dependence on any
context?
∂01-Sep-83 1632 @USC-ECL,@MIT-MC:Deutsch.PA@PARC-MAXC Re: Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 1 Sep 83 16:31:50 PDT
Received: from MIT-MC by USC-ECL; Thu 1 Sep 83 16:30:03-PDT
Date: Thu, 1 Sep 83 16:19 PDT
From: Deutsch.PA@PARC-MAXC.ARPA
Subject: Re: Function cells
In-reply-to: "Bobrow's message of Thu, 1 Sep 83 14:30 PDT"
To: Bobrow.PA@PARC-MAXC.ARPA
cc: TIM%MIT-OZ@MIT-MC.ARPA, lisp-forum@MIT-MC.ARPA, Julian Padget
<PADGET@UTAH-20.ARPA>, Teitelman.PA@PARC-MAXC.ARPA
Danny,
I have to side with the Common Lisp / T people on this one. Just
because most (but not all) function invocations use names that are bound
in a global, flat name space (which all modern Lisp systems are finding
ways to enrich), and most (but not all) variables are bound more locally
(in this lexical scope? in a dynamically enclosing but far-from-apparent
scope? in an enclosing lexical scope?), is not enough of a reason for
introducing a mechanism that adds complexity all over the system.
T takes the viewpoint that all identifiers are on a par. The compiler
is able to take advantage of pragmatic information about things being
constant or not dynamically rebound, regardless of whether they are
functions or variables. I imagine Common Lisp is the same.
Function cells seemed like a good idea at the time, just like
GLOBALVARS. I think they were both pragmatic successes and semantic
mistakes.
∂01-Sep-83 1707 @USC-ECL,@MIT-MC:PADGET@UTAH-20 Re: Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 1 Sep 83 17:06:12 PDT
Received: from MIT-MC by USC-ECL; Thu 1 Sep 83 16:58:45-PDT
Date: 1 Sep 1983 1746-MDT
From: Julian Padget <PADGET@UTAH-20>
Subject: Re: Function cells
To: BOBROW.PA@PARC-MAXC
cc: Padget@UTAH-20, DEUTSCH.PA@PARC-MAXC, LISP-FORUM@MIT-MC,
TEITELMAN.PA@PARC-MAXC, TIM%MIT-OZ@MIT-MC
In-Reply-To: Your message of 1-Sep-83 1551-MDT
As an aside to the main discussion, I do not condone the use of both
the function and the value cell as a programming style, I am also doubtful
about Tim's appellation of this as a feature.
I should also remark that there are some 'real' LISPs that only provide
one location for keeping a value associated with an id (ie no function cell),
in particular Cambridge LISP.
I would vote with Tim to remove this dichotomy which is being continued in
Common LISP, for reasons which are given in more detail below. However I
strongly suspect that the main reason for its retention in CL is not for
aesthetic but political motives - how else is MACSYMA going to run under CL,
the coding style therein uses this 'feature' quite a lot, and rewriting
all the affected parts is not an overnight job.
I maintain that a function IS a value, and the distinction between value
and function is erroneous. Although no-one would seriously regard LISP as a
faithful implementation of the semantics of lambda calculus, it is not
unreasonable to pay lip service to its (our??) heritage.
With respect to the question of clarity: there is a problem with the
handling of anonymous functions (as in say the MAP functions), and in the
case of high order functions. Although this example may seem somewhat
contrived, it is relevant.
R-Sum and I-sum define functions to do a curried summation (I provide
both for a little variety):
(De R-Sum (a0)
(Function
(Lambda (ai)
(Cond ((Zerop ai) a0) (t (R-Sum (Plus a0 ai)))))))
alternatively:
(De I-Sum (a0)
(Prog (fn)
(Return
(SetQ fn
(Function
(Lambda (ai)
(Cond ((Zerop ai) a0) (t (SetQ a0 (Plus a0 ai))))
fn))))))
now using these in a single cell system gives rise to the following
expression:
(((((I-sum 1) 2) 3) 4) 0)
if FUNCALL must be used this becomes:
(FunCall (FunCall (FunCall (FunCall (I-sum 1) 2) 3) 4) 0)
In addition to being a matter of style/personal taste, it is a
question of consistency (as Peter Deutsch remarked), each element of
a form is treated the same way - even assuming the first element is
evaluated repeatedly until an object which can be applied is found, since
that is simply a recursion in eval without passing the rest of the form
downwards.
--Julian Padget.
-------
∂01-Sep-83 1817 @USC-ECL,@MIT-MC:Bobrow.PA@PARC-MAXC Re: Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 1 Sep 83 18:16:40 PDT
Received: from MIT-MC by USC-ECL; Thu 1 Sep 83 18:15:58-PDT
Date: Thu, 1 Sep 83 18:11 PDT
From: Bobrow.PA@PARC-MAXC.ARPA
Subject: Re: Function cells
In-reply-to: "BENSON@SPA-Nimbus.ARPA's message of Thu, 1 Sep 83 15:35
PDT"
To: Eric Benson <BENSON@SPA-Nimbus.ARPA>
cc: Bobrow.PA@PARC-MAXC.ARPA, TIM%MIT-OZ@MIT-MC.ARPA,
Deutsch.PA@PARC-MAXC.ARPA, lisp-forum@MIT-MC.ARPA, Julian Padget
<PADGET@UTAH-20.ARPA>, Teitelman.PA@PARC-MAXC.ARPA
I don't object to definitions which depend on context. I like to see
uses which depend on such context dependent definitions distinguished
from ones which don't.
∂03-Sep-83 1232 @USC-ECL,@MIT-MC:ZVONA@MIT-OZ Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 3 Sep 83 12:32:21 PDT
Received: from MIT-MC by USC-ECL; Sat 3 Sep 83 11:50:24-PDT
Date: Sat, 3 Sep 1983 14:38 EDT
Message-ID: <[MIT-OZ].ZVONA. 3-Sep-83 14:38:45>
From: ZVONA@MIT-OZ
To: Bobrow.PA@PARC-MAXC.ARPA
Cc: Eric Benson <BENSON@SPA-Nimbus.ARPA>, Deutsch.PA@PARC-MAXC.ARPA,
lisp-forum@MIT-MC.ARPA, Julian Padget <PADGET@UTAH-20.ARPA>,
Teitelman.PA@PARC-MAXC.ARPA, TIM%MIT-OZ@MIT-MC.ARPA
Subject: Function cells
In-reply-to: Msg of 1 Sep 1983 21:11-EDT from Bobrow.PA at PARC-MAXC.ARPA
The "function spec" problem in Common Lisp is one that makes clear the
advantages of treating "functions and values" uniformly.
It is common to store functions as properties of symbols. This allows
a clean implementation of data-directed dispatching: you write
(funcall (get snabozzle 'quibbix) . args) in order to do a
quibbix-type dispatch on the snabozzle. To support this, you want a
clean way to write the functions that will be stored on the property
list and to get them into the property list. In a lambda calculus
system, you might write
(put 'some-snabozzle 'quibbix (lambda ...))
but modern lisps have defun, which has a lot of useful syntax that
you'd like to use in defining the dispatched-to functions.
Maclisp provided the syntax
(defun (some-snabozzle quibbix) arglist . body)
which would effectively macroexpand into the same thing (and also hack
defun-syntax and process declarations and so forth for you). This
syntax had a number of problems; among them, especially, that besides
the "function cell" and properties there are other places that you
might want to store functions. Therefore, lisp machine lisp did an
almost-upward-compatible extension to this in which the defun name
(first subform) if a list would dispatch on the car of the list if
possible. The car of the list could then be a keyword that would tell
where to put the function.
(defun (:property some-snabozzle quibbix) arglist . body)
for example. These lists (such as (:property ...)) were called
"function specs". The lisp machine provides for each function spec a
set of things that can be done to it: you can define it, undefine it
(make it unbound), get its definition, and so on.
All this amounts to a fair amount of conceptual overhead (though to
total amount of code to implement it fits in a few pages). It is no
longer obvious just what it is that defun abstractly macroexpands
into; it is doing some magic with the function specs behind your back.
Moreover, it is often unclear in what contexts it is allowable to use
a function spec. For example, beginners who are first introduced to
function specs often try to write
((:property snabozzle quibbix) . args)
or
(funcall (:property snabozzle quibbix) . args)
This suggests that perhaps what one ought to be writing is
(defun (get 'some-snabozzle 'quibbix) arglist . body)
because it is intuitively clearer if the defining and using forms have
the same syntax. Moreover, this eliminates all the overhead of
function specs. And then defun again has a clear macroexpansion: it
is really just sugar for setf! That is, the defun above is really
(setf (get 'some-snabozzle 'quibbix) (lambda arglist . body))
There is just one difficulty with this: what does
(defun drofnats (self) (capitalize (string-reverse self)))
macroexpand into? It ought to be
(setf drofnats (lambda (self) (capitalize (string-reverse self))))
but that sets the value cell, not the function cell!
This, finally, is the point: The elegant setf syntax for defun was
abandoned for common lisp because it didn't "work" on symbols. The
true story is that the uniform handling of functions as values is a
self-consistent system, and function cells are a confused mess.
*** *** *** ***
It is worth mentioning that (function ...) is intimately tied up with
the function cell lossage. Common lisp weirdly chose to implement
lambda right, but to require a no-op #' in front of it. (Anyone who
wants to win, of course, can define lambda as a macro that expands
into #'(lambda ...). Takes all kinds.)
*** *** *** ***
Common lisp people:
defun setf syntax seems like such a win that perhaps it could be
salvaged by the following klduge (which seems better than function
specs):
defun has setf-syntax except on symbols. It uses the function cell
with symbols. You can set the value cell of a symbol with
(defun (symbol-value symbol) ...)
∂03-Sep-83 1833 @USC-ECL,@MIT-MC:RWK@SCRC-TENEX Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 3 Sep 83 18:30:54 PDT
Received: from MIT-MC by USC-ECL; Sat 3 Sep 83 18:28:19-PDT
Received: from SCRC-YUKON by SCRC-TENEX with CHAOS; Sat 3-Sep-83 21:12:55-EDT
Date: Saturday, 3 September 1983, 21:06-EDT
From: Robert W. Kerns <RWK at SCRC>
Subject: Function cells
To: ZVONA at OZ, Bobrow.PA at PARC-MAXC
Cc: BENSON at SPA-Nimbus.ARPA, Deutsch.PA at PARC-MAXC, lisp-forum at MC,
PADGET at UTAH-20, Teitelman.PA at PARC-MAXC, TIM%MIT-OZ at MC
In-reply-to: <[MIT-OZ].ZVONA. 3-Sep-83 14:38:45>
Date: Sat, 3 Sep 1983 14:38 EDT
From: ZVONA@MIT-OZ
The "function spec" problem in Common Lisp is one that makes clear the
advantages of treating "functions and values" uniformly.
It is common to store functions as properties of symbols. This allows
a clean implementation of data-directed dispatching: you write
(funcall (get snabozzle 'quibbix) . args) in order to do a
quibbix-type dispatch on the snabozzle. To support this, you want a
clean way to write the functions that will be stored on the property
list and to get them into the property list. In a lambda calculus
system, you might write
(put 'some-snabozzle 'quibbix (lambda ...))
but modern lisps have defun, which has a lot of useful syntax that
you'd like to use in defining the dispatched-to functions.
Maclisp provided the syntax
(defun (some-snabozzle quibbix) arglist . body)
which would effectively macroexpand into the same thing (and also hack
defun-syntax and process declarations and so forth for you). This
syntax had a number of problems; among them, especially, that besides
the "function cell" and properties there are other places that you
might want to store functions. Therefore, lisp machine lisp did an
almost-upward-compatible extension to this in which the defun name
(first subform) if a list would dispatch on the car of the list if
possible. The car of the list could then be a keyword that would tell
where to put the function.
(defun (:property some-snabozzle quibbix) arglist . body)
for example. These lists (such as (:property ...)) were called
"function specs". The lisp machine provides for each function spec a
set of things that can be done to it: you can define it, undefine it
(make it unbound), get its definition, and so on.
All this amounts to a fair amount of conceptual overhead (though to
total amount of code to implement it fits in a few pages). It is no
longer obvious just what it is that defun abstractly macroexpands
into; it is doing some magic with the function specs behind your back.
Moreover, it is often unclear in what contexts it is allowable to use
a function spec. For example, beginners who are first introduced to
function specs often try to write
((:property snabozzle quibbix) . args)
or
(funcall (:property snabozzle quibbix) . args)
This suggests that perhaps what one ought to be writing is
(defun (get 'some-snabozzle 'quibbix) arglist . body)
No, one should write (funcall #'(:property snaboozle quibbix) . args)
just like one should write (funcall #'snaboozle . args) or
(funcall #'(lambda (x) (+ x x)) . args). The non-uniformity
here is that (funcall 'snaboozle . args) or
(funcall '(lambda (x) (+ x x)) . args) will work at all.
The only problem with writing ((:property snabozzle quibbix) . args)
is that it is visually confusing. You can't argue that because
((:property snabozzle quibbix) . args) doesn't work that the
idea of a function spec is inelegant! At most you can say that
a piece of it that should work doesn't.
because it is intuitively clearer if the defining and using forms have
the same syntax. Moreover, this eliminates all the overhead of
function specs. And then defun again has a clear macroexpansion: it
is really just sugar for setf!
Bullshit. DEFUN started out life as sugar for DEFPROP, not PUTPROP.
The difference is that the compiler was then considered free to compile
things defined with DEFPROP. In more modern times, the compiler is
considered free to compile things "quoted" with FUNCTION rather than
QUOTE. So...
That is, the defun above is really
(setf (get 'some-snabozzle 'quibbix) (lambda arglist . body))
There is just one difficulty with this: what does
(defun drofnats (self) (capitalize (string-reverse self)))
macroexpand into? It ought to be
(setf drofnats (lambda (self) (capitalize (string-reverse self))))
but that sets the value cell, not the function cell!
In the current scheme,
(DEFUN FOO (X) (BAR X)) ==>
(SETF #'FOO #'(LAMBDA (X) (BAR X)))
(DEFUN (:PROPERTY FOO :FUN-PROP) (X) (BAR X)) ==>
(SETF #'(:PROPERTY FOO :FUN-PROP) #'(LAMBDA (X) (BAR X)))
This, finally, is the point: The elegant setf syntax for defun was
abandoned for common lisp because it didn't "work" on symbols. The
true story is that the uniform handling of functions as values is a
self-consistent system, and function cells are a confused mess.
That is indeed the problem with your scheme, it turns function cells
into a confused mess. It also ignores every shred of consistancy in
favor of your own internal confusion. Proof by Solipsism is not
acceptable.
*** *** *** ***
It is worth mentioning that (function ...) is intimately tied up with
the function cell lossage. Common lisp weirdly chose to implement
lambda right, but to require a no-op #' in front of it. (Anyone who
wants to win, of course, can define lambda as a macro that expands
into #'(lambda ...). Takes all kinds.)
You're right, it is connected. You can view (FUNCTION ...) as meaning
"do what you do to the CAR of a combination to get the function to be
performed". It doesn't buy you much to say that what you do with
the FIRST of a form should be the same as what you do the the SECOND.
It just isn't true after you get your hands on the function, especially
in the case of macros.
The distinction here is very much like the distinction between nouns
and verbs in English. Frequently a word is both a noun and a verb,
but the distinction is clear from context. For example, LIST is both
a noun and a verb. I have seen many users of lisps without function
cells SCREW THEMSELVES TO THE WALL by using something as a temporary
variable that happens to also be a function name. LIST is the most
common offender. (This is made worse by lisps which defaultly use
dynamic scoping, but people also have screwed themselves doing
(SETQ LIST (GET-ITEM-LIST 'FOO)) at top level).
*** *** *** ***
Common lisp people:
defun setf syntax seems like such a win that perhaps it could be
salvaged by the following klduge (which seems better than function
specs):
defun has setf-syntax except on symbols. It uses the function cell
with symbols. You can set the value cell of a symbol with
(defun (symbol-value symbol) ...)
ARGH! This does nobody any favors. It is every bit as bad as you
imagine distinguishing between functions and values is.
This debate really annoys me, partly because not a single new thing has
been said (with the exception of your SETF/DEFUN scheme, which I detest).
Most of the people involved with Common Lisp have faced this issue and
been thinking about it for 5 years or more. Most of the arguments against
it are based on an unstated assumption that saying (FUNCALL X ...) is
an unwanted complexity rather than a helpful clarification, or that
the slight simplification of eliminating the function cell is worth
sacraficing the clarity, or that the slight simplification of calling
EVAL on the CAR of the form is worth anything at all.
What I don't understand is why everybody goes on about the FUNCTION cell
in favor of the VALUE cell. Why isn't anybody proposing we do away with
the VALUE cell. The history of the VALUE cell in MacLisp *IS THE SAME
AS THAT OF THE FUNCTION CELL*. I.e. they both used to simply be
properties on the property list. The evaluator would do a (GET SYMBOL
'VALUE), just like it would do a (GET SYMBOL 'EXPR). It is obvious that
these are both properties of a symbol, just like (GET SYMBOL 'SI:FLAVOR)
is.
Really, let's not go half-way. Let's take the argument for merging the
VALUE and FUNCTION properties to its logical extreme, and eliminate the
property-list altogether!
Personally, I'd rather keep distinct meanings separate (noun-meaning
(value), verb-meaning (function), adjective-meaning (flavor)), and try
to have the most EXPRESSIVE language, not the SIMPLEST language.
∂05-Sep-83 1235 @USC-ECL,@MIT-MC:Moon@SCRC-TENEX Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 5 Sep 83 12:35:29 PDT
Received: from MIT-MC by USC-ECL; Mon 5 Sep 83 12:05:35-PDT
Received: from scrc-schuylkill by scrc-cupid with CHAOS; 5 Sep 1983 14:45:22-EDT
Date: Monday, 5 September 1983, 14:52-EDT
From: David A. Moon <Moon at SCRC>
Subject: Function cells
To: ZVONA at OZ, RWK at SCRC, BENSON at NIMBUS, Bobrow.PA at PARC-MAXC,
Deutsch.PA at PARC-MAXC, PADGET at UTAH-20,
Teitelman.PA at PARC-MAXC, TIM at OZ
Cc: lisp-forum at MC
Could the people who are interested in this "function cells" discussion
please move it to another mailing list, where I don't have to see it?
If other people on Lisp-forum feel that the discussion should continue
on Lisp-forum, please send mail to me directly and if enough people
so believe I will remove myself from lisp-forum.
∂05-Sep-83 1325 @USC-ECL,@MIT-MC:jkf%ucbkim@Berkeley Re: Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 5 Sep 83 13:25:23 PDT
Received: from MIT-MC by USC-ECL; Mon 5 Sep 83 13:24:39-PDT
Received: from ucbkim.ARPA by ucbvax.ARPA (4.9/4.7)
id AA12745; Mon, 5 Sep 83 13:21:08 PDT
Received: by ucbkim.ARPA (4.6/4.2)
id AA15598; Mon, 5 Sep 83 13:20:31 PDT
Date: Mon, 5 Sep 83 13:20:31 PDT
From: jkf%ucbkim@Berkeley (John Foderaro)
Message-Id: <8309052020.AA15598@ucbkim.ARPA>
To: Moon@SCRC
Subject: Re: Function cells
Cc: lisp-forum@MC
In-Reply-To: Your message of Monday, 5 September 1983, 14:52-EDT
While I am not particularly interested in the discussion on function cells,
I think that lisp-forum is the precise place to have such a discussion for
those who are interested.
I've never understood why so many people insist on stifiling discussions on
mailing lists. I can only conclude that there are a lot of crufty mail
reading programs out there that force you to read every character of every
letter you receive.
∂05-Sep-83 1347 @USC-ECL,@MIT-MC:ZVONA@MIT-OZ Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 5 Sep 83 13:46:26 PDT
Received: from MIT-MC by USC-ECL; Mon 5 Sep 83 11:11:10-PDT
Date: Mon, 5 Sep 1983 13:41 EDT
Message-ID: <[MIT-OZ].ZVONA. 5-Sep-83 13:41:00>
From: ZVONA@MIT-OZ
To: Robert W. Kerns <RWK@SCRC-TENEX>
Cc: BENSON@SPA-Nimbus.ARPA, Bobrow.PA@PARC-MAXC, Deutsch.PA@PARC-MAXC,
lisp-forum@MIT-MC, PADGET@UTAH-20, Teitelman.PA@PARC-MAXC,
TIM%MIT-OZ@MIT-MC
Subject: Function cells
In-reply-to: Msg of 3 Sep 1983 21:06-EDT from Robert W. Kerns <RWK at SCRC>
Well. There are probably people who can argue this better, but none
have stepped forward, so...
What I don't understand is why everybody goes on about the FUNCTION cell
in favor of the VALUE cell. Why isn't anybody proposing we do away with
the VALUE cell. The history of the VALUE cell in MacLisp *IS THE SAME
AS THAT OF THE FUNCTION CELL*. Really, let's not go half-way.
Let's take the argument for merging the VALUE and FUNCTION
properties to its logical extreme, and eliminate the property-list
altogether!
I think that is a good idea. (This step was seriously discussed in
the design of T.) The whole idea of symbols is overloaded and
bankrupt. The different uses and features of symbols ought to be
separated out. First, there is the idea of INTERNED STRINGS, a useful
user-interface feature. So we'll have such a datatype. Then there is
the separate idea of NAMES: any object can name another; to an object,
you can associate a value and retrieve it efficiently. (T lets you
associate a value with any S-expression.) Quite another idea is that
of PROPERTIES; Brand-X and (I think) MIT-scheme allow any object to
have properties associated with it; there is nothing special about
``symbols''. I never use properties, myself; I think that they are
almost always an artifact of unclear thought, and that you'd do better
to use something else. The main uses are in user interface, when a
user uses a symbol to name a structure, in which case you'd do better
to use a hashtable that maps symbols to their associated structure;
and in storing random crufties, in which case you should probably be
using DEFSTRUCT.
Unfortunately, naming is currently all mixed up with EVAL, which is
pretty much bankrupt itself. The reason that currently symbols have
values and not other things is that the main thing that gets values is
EVAL, and other things mean something special to EVAL. So lists, for
example, will not have their values used much, and from what I can
see, T makes no use of the extended variable feature.
Brian Smith's thesis straightens this particular mess out by replacing
EVAL with two things: NORMALIZE, and DOWN-ARROW. DOWN-ARROW gets the
``value'' of something: the thing that is designated by its argument.
NORMALIZE simplifies expressions. If you want to understand what
QUOTE is really for, and how naming should work, you should read his
thesis (it's an LCS TR). But his 2-LISP is probably too outre' to
discuss on this mailing list.
... You can view (FUNCTION ...) as meaning
"do what you do to the CAR of a combination to get the function to be
performed". It doesn't buy you much to say that what you do with
the FIRST of a form should be the same as what you do the the SECOND.
It just isn't true after you get your hands on the function, especially
in the case of macros.
Your point here (which must be the crux of your argument) is not quite
clear to me. Obviously the car of all forms can not be treated the
same way as the other subforms; but in the case of special forms such
as SETQ, various non-car subforms are treated in different ways
anyway. The issue is meaningful only for forms that are simple
combinations, i.e. function applications. [FUNCTION of a symbol that
refers to a macro returns something completely random on the lisp
machine, anyway. What does your last sentence mean?] The fact is
that even for simple combinations, the CAR is treated specially, since
it is the one that is applied to all the others. The claim is not
that the uniformity of handling at this level is especially winning.
The uniformity really arises from the fact that there is only one
thing going on here, and that is NAMING. And the names of functions
are no different from the names of anything else.
I have seen many users of lisps without function
cells SCREW THEMSELVES TO THE WALL by using something as a temporary
variable that happens to also be a function name. LIST is the most
common offender. (This is made worse by lisps which defaultly use
dynamic scoping, but people also have screwed themselves doing
(SETQ LIST (GET-ITEM-LIST 'FOO)) at top level).
There are lots of ways to screw yourself when you are first learning
Lisp. (Try tracing PRINT.) In a language that is lexically scoped
and in which the system functions are locked and sacred (as, I
believe, they are in MIT scheme) the danger is much reduced, and not
worth making the language counter-intuitive over.
because it is intuitively clearer if the defining and using forms have
the same syntax. Moreover, this eliminates all the overhead of
function specs. And then defun again has a clear macroexpansion: it
is really just sugar for setf!
Bullshit. DEFUN started out life as sugar for DEFPROP, not PUTPROP.
The difference is that the compiler was then considered free to compile
things defined with DEFPROP. In more modern times, the compiler is
considered free to compile things "quoted" with FUNCTION rather than
QUOTE. So...
In an ideal world (which is not even particularly hard to achieve --
the MIT scheme implementation, at least, succeeds) there should be no
difference between code to be compiled and code to be interpreted
(except for declarations that will allow the compiler to optimize code
without changing the semantics). It should never be necessary for the
user to reason about differences between the behaviors of his program
compiled and interpreted. Any sort of ``compilable contexts'' kludge
such as #', special handling of DEFPROP, and (PROGN 'COMPILE ...)
makes it much less clear what the compiler is doing, and harder to
think about how to write code.
You can't argue that because
((:property snabozzle quibbix) . args) doesn't work that the
idea of a function spec is inelegant! At most you can say that
a piece of it that should work doesn't.
Certainly it would be an incremental improvement if this worked.
In the current scheme,
(DEFUN (:PROPERTY FOO :FUN-PROP) (X) (BAR X)) ==>
(SETF #'(:PROPERTY FOO :FUN-PROP) #'(LAMBDA (X) (BAR X)))
This doesn't work currently on the lisp machine. Presumably it does
in the incomplete Common Lisp function spec proposal.
(defun (symbol-value symbol) ...)
ARGH! This does nobody any favors. It is every bit as bad as you
imagine distinguishing between functions and values is.
OK, fair enough, this sucked.
Most of the people involved with Common Lisp have faced this issue and
been thinking about it for 5 years or more.
So have the Scheme people; so have I, for that matter. [Disclaimer: I
do not work on any brand of Scheme, and am quite skeptical of all
existing implementations. I use lisp machines, which are clearly a
vastly superior programming system, even though the Lisp they are
based on is a little crufty.]
Most of the arguments against [function cells] are based on an
unstated assumption that saying (FUNCALL X ...) is
an unwanted complexity rather than a helpful clarification, or that
the slight simplification of eliminating the function cell is worth
sacraficing the clarity, or that the slight simplification of calling
EVAL on the CAR of the form is worth anything at all.
These assumptions aren't really unstated; they are firm convictions of
many people. Some people that have programmed in languages both with
and without funtion cells find those without to be much clearer; no
sacrifice is involved.
∂05-Sep-83 1625 @USC-ECL:GJC@MIT-MC Zippy the mailer, or ... are we on the net yet?
Received: from USC-ECL by SU-AI with TCP/SMTP; 5 Sep 83 16:25:29 PDT
Received: from MIT-MC by USC-ECL; Mon 5 Sep 83 16:25:30-PDT
Date: 5 September 1983 19:15 EDT
From: George J. Carrette <GJC @ MIT-MC>
Subject: Zippy the mailer, or ... are we on the net yet?
To: jkf @ UCBKIM
cc: LISP-FORUM @ MIT-MC, Moon @ SCRC-TENEX
In-reply-to: Msg of Mon 5 Sep 83 13:20:31 PDT from jkf%ucbkim at Berkeley (John Foderaro)
Really now. In all probability Dave Moon is reading his mail on his
own personal lisp machine which has about as much or more physical memory and
speed as your usual DEC-20 or VAX-11/780 installation for 50 users, so it just
doesn't make much sense in this case to be making snide comments about
poor quality mail reading programs in the context of stifiling
discussions on mailing lists.
Given that bit of information, maybe you can just take Daves very polite
comment at face value.
-gjc
∂06-Sep-83 1759 @USC-ECL,@MIT-MC:PADGET@UTAH-20 Re: Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 6 Sep 83 17:58:47 PDT
Received: from MIT-MC by USC-ECL; Tue 6 Sep 83 17:54:14-PDT
Date: 6 Sep 1983 1844-MDT
From: Julian Padget <PADGET@UTAH-20>
Subject: Re: Function cells
To: Moon@SCRC-TENEX, lisp-forum@MIT-MC
cc: Padget@UTAH-20
In-Reply-To: Your message of 5-Sep-83 1304-MDT
Since it was I who initiated this discussion, I feel it behoves me
to reply to Dave Moon.
For the most part the messages on the subject of function cells have
been concise and factual. I do not wish to slander anybody but 'flaming'
only became a problem when some people from MIT joined. The message length
problem has been exacerbated by the popularity of inserting ones own
comments into a message to construct a reply. An alternative is a few
minutes with a pencil and paper, and serves to clarify the mind wonderfully.
The subject matter seems entirely suited to lisp-forum; one cannot
always expect everything in such a digest to be of interest to everyone,
thus I find your reaction surprising and somewhat churlish.
I hope you take these remarks in the spirit in which they are intended.
--Julian Padget.
-------
∂06-Sep-83 1814 @USC-ECL:KMP@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 6 Sep 83 18:14:00 PDT
Received: from MIT-MC by USC-ECL; Tue 6 Sep 83 18:10:35-PDT
Date: 6 September 1983 19:17 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: DCP @ MIT-MC
cc: RWK @ MIT-MC, ALAN @ MIT-MC, BUG-MACLISP @ MIT-MC, GJC @ MIT-MC,
GUMBY @ MIT-MC
Uh, I believe the story is...
WHEN and UNLESS are in UMLMAC.
They have been there for ages; since long before the LispM adopted them.
It took forever to convince the LispM people that they were a win because
there was a stubbornness on the part of the LispM designers who claimed
that there were already too many control constructs in LispM lisp and that
people should use AND and OR for simple cases and IF/COND for the hairier
cases.
I believe the justification for them being in UMLMAC and not being autoloading
stemmed from the fact that no one was willing to standardize them into
the LispM. I think that now that they have gained acceptance in the LispM
community that it would be an extremely good idea if they became standard
in Maclisp as well.
It seems that my manual doesn't document them, even as something you could
make autoload. That's a bit sad.
∂06-Sep-83 1814 @USC-ECL:DCP@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 6 Sep 83 18:14:29 PDT
Received: from MIT-MC by USC-ECL; Tue 6 Sep 83 18:11:06-PDT
Date: 6 September 1983 20:30 EDT
From: David C. Plummer <DCP @ MIT-MC>
To: KMP @ MIT-MC
cc: DCP @ MIT-MC, RWK @ MIT-MC, ALAN @ MIT-MC, BUG-MACLISP @ MIT-MC,
GJC @ MIT-MC, GUMBY @ MIT-MC
Date: 6 September 1983 19:17 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
GUMBY @ MIT-MC
Uh, I believe the story is...
WHEN and UNLESS are in UMLMAC.
...
Yow!! Information and historical perspective! I think we're all
agreed that they should appear in the standard MacLisp, and Alan
mumbled "some day..." which I hope means the next time he has a
hack attack and builds a new MacLisp.
∂17-Sep-83 1709 @USC-ECL:RIVIN@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 17 Sep 83 17:09:11 PDT
Received: from MIT-MC by USC-ECL; Sat 17 Sep 83 17:08:57-PDT
Date: 17 September 1983 20:08 EDT
From: Igor Rivin <RIVIN @ MIT-MC>
To: BUG-MACLISP @ MIT-MC
Calling GRIND0 on a file which contains the form
(defun foo (l) (mapcar #'list l))
causes a ;BKPT *RSET-TRAP probably because of the # reader macro.
∂17-Sep-83 1859 @USC-ECL,@MIT-MC:GLR@MIT-OZ SETSYNTAX and (STATUS CHTRAN) on TOPS-20
Received: from USC-ECL by SU-AI with TCP/SMTP; 17 Sep 83 18:59:00 PDT
Received: from MIT-MC by USC-ECL; Sat 17 Sep 83 18:55:17-PDT
Date: Sat, 17 Sep 1983 21:53 EDT
Message-ID: <[MIT-OZ].GLR.17-Sep-83 21:53:22>
From: Jerry Roylance <GLR@MIT-OZ>
To: BUG-LISP@MIT-OZ
Subject: SETSYNTAX and (STATUS CHTRAN) on TOPS-20
;;; Bug in MACLISP
;;; setsyntax screws chtran
;;;
(defun maclisp-bug ()
(let ((readtable (*array nil 'readtable)))
(setsyntax #/, 'single nil)
(print (status macro #/,))
(print (status chtran #/,))
(sstatus macro #/, nil)
(print (status chtran #/,))
NIL
))
I suspect that setsyntax does completely remove the , readmacro.
∂21-Sep-83 2258 @USC-ECL,@MIT-MC:kmp@MIT-MC TYIPEEK and SFAs -- A longstanding bug that needs fixing
Received: from USC-ECL by SU-AI with TCP/SMTP; 21 Sep 83 22:58:32 PDT
Received: from MIT-MC by USC-ECL; Wed 21 Sep 83 22:55:14-PDT
Date: Thursday, 22 September 1983, 01:52-EDT
From: Kent M. Pitman <kmp at MIT-MC>
Subject: TYIPEEK and SFAs -- A longstanding bug that needs fixing
To: Alan at MC
Cc: BUG-MACLISP at MIT-MC
I got mail from you a couple months ago saying you wanted to flush
Maclisp 1914 from MC but I was locking the dump with my Fortran
translator. I finally found the bug report which describes the
reason the translator doesn't run in a later version of Lisp. I'd
appreciate it if you could look at this bug, as I do consider it
rather severe... I just checked and all the reported symptoms still
occur as described in Lisp 2138 on MC.
-----Begin Dredged Up Mail-----
Date: 20 May 1981 04:23-EDT
From: Kent M. Pitman <KMP>
To: BUG-MACLISP
Re: TYIPEEK / SFA interaction changed??
It used to be that the following definition
(DEFUN SFA-HANDLER (SELF OP DATA)
(CASEQ OP ((WHICH-OPERATIONS) '(TYIPEEK))
((TYIPEEK) DATA)
(T (ERROR "I am too dumb to do that" OP))))
(SETQ STREAM (SFA-CREATE #'SFA-HANDLER 0. "Dumb Stream"))
would allow you to do
(TYIPEEK NIL STREAM) => -1
(TYIPEEK NIL STREAM -1) => -1
(TYIPEEK NIL STREAM -3) => -3
even tho
(TYIPEEK NIL (OPEN 'NUL: 'IN) -1) => -1
(TYIPEEK NIL (OPEN 'NUL: 'IN) -3) => -1 ; this was a bug then and still is now
Anyway, now you get the following behavior instead:
(TYIPEEK NIL STREAM) => ;NIL NON-FIXNUM VALUE
(TYIPEEK NIL STREAM -1) => ;NIL NON-FIXNUM VALUE
In an EOF case, the TYIPEEK message to an SFA must be able to return its DATA
argument. DATA used to get bound to #nnnnnn and somehow if you returned this,
it magically figured out you wanted the eof value returned to the user. Now I
would prefer that DATA be bound to the value supplied (default -1 if
none supplied), but that's just preference. The important thing tho' is that
I have code that is broken until someone fixes the TYIPEEK message to pass
some piece of data which if returned will give the right value back from
TYIPEEK without erring...
Naturally, while you're at it you could fix that other bug wherein only -1
can be returned from an EOF on a real file object when TYIPEEK'ing, even if
some other arg is supplied (see the -3 case above).
-kmp
Date: 21 May 1981 02:13-EDT
From: Alias for KMP <TURNIP>
To: BUG-MACLISP
Re: more on yesterday's TYIPEEK lossage
INCST3: TLNE T,SO.TIP ;FOO! TYIPEEK IS DIFFERENT!
TDZA C,C ; BUT IF NOT TYIPEEK THEN USE
MOVEI C,INCST3 ; NEW EOF VALUE, SOMETHING UNIQUE
PUSHJ P,ISTCAL ;CALL THE SFA
POP P,C ;RESTORE EOF VALUE
CAIN A,INCST3 ;DID THE SFA RETURN EOF?
JRST INCST4 ;YES, HANDLE IT
JSP T,FXNV1 ;ELSE THE VALUE RETURNED MUST BE A FIXNUM
POPJ P,
-----
Note how SFA's get sent a NIL but on return check for INCST3 ...? How is
the guy going to know to return that? I just did
(SETQ STREAM (SFA-CREATE #'(LAMBDA (SELF OP DATA)
(CASEQ OP
((WHICH-OPERATIONS) '(TYIPEEK))
((TYIPEEK) '#,(MUNKAM (GETDDTSYM 'INCST3)))
(T (ERROR "Loss" OP))))
0. "Loss"))
(TYIPEEK NIL STREAM) => -1.
(TYIPEEK NIL STREAM -3) => -3.
which is the kind of behavior that I want... Somehow this need for
#,(MUNKAM ...) seems awkward, though.
∂27-Sep-83 1631 @USC-ECL,@MIT-MC:JonL.pa@PARC-MAXC Function Cells -- the history
Received: from USC-ECL by SU-AI with TCP/SMTP; 27 Sep 83 16:28:57 PDT
Received: from MIT-MC by USC-ECL; Tue 27 Sep 83 16:26:45-PDT
Date: Tue, 27 Sep 83 16:16 PDT
From: JonL.pa@PARC-MAXC.ARPA
Subject: Function Cells -- the history
To: Padget@Utah-20.ARPA
cc: Lisp-Forum@MIT-MC.ARPA
There are two parts to your question:
1) who first converted atoms (i.e. LITATOMs or SYMBOLs) from list
structure with weird pointer in the first CAR, to standard block
record structure, and
2) who first differentiated between function context and argument
context when interpreting an atom.
No doubt, there is an element of "why" in your question too.
RE point 1:
Peter Deutsch's answer is quite correct as far as I know -- BBN Lisp
(predecessor to InterLisp) in mid 1960's. The arguments I heard in
later years for justification had more to do with paging behaviour
of compiled code rather than any other. It was *not* (emphasize!) for
the purpose of implementing point 2.
Interestingly, VAX/NIL had a modified "structure" for SYMBOLs; it had
been noted in MACSYMA that big systems could easily contain 2000 or
more symbols, only a small fraction of which utilised both the function
cell and the value cell. So for space saving a kludge was perpetrated in
which every symbol had one cell which was a pointer to either a function
cell, or a value cell, or a more standard block record of all requisite cells.
The reason this was "space saving" was that the implementation of
Local-vs-Dynamic and Function-vs-Value are independent, and thus in
fullness, one needs 4 (four!) value cells. Speed of access isn't an issue,
since compiled code normally links thru the value cell itself (or function
cell, if you must) rather than thru the symbol header; also, the extra cost
for this "hair" is verry small in terms of VAX instructions.
RE point 2:
Did any of the replies to you so far note that this differentiation was
part of Lisp1.5.? See page 18 of the "LISP 1.5 Programmer's Manual" where
the classic scheme is described. I did not "invent" this scheme. Neither
did MacLisp, nor its predecessor PDP6 Lisp, originate it. It was inherited
directly from Lisp 1.5 and CTSS Lisp [remember CTSS? the "Compatible Time
Sharing System" on a greatly modified IBM 7090? Most of the Lisp world
remembers only ITS -- "Incompatible Timesharing System" -- and now it too
is passing away. Sic Transit Gloria Mundi (sic)]
I venture the opinion that the underlying reason why "uniform" treatment
of identifiers is ever thought to be desirable is that it somewhat simplifies
the coding and conceptual complexity of the interpreter/system. There is a
strong series of arguments *against* this "optimisation", made by users of
said systems. Dan Bobrow offered the most compelling of these in his
answer: essentially stated, there is a general expectation that the function
name space is global, unless otherwise stated, and that the variable name
space is local, unless otherwise stated. Once this distinction is admitted,
there is little point in trying to force both meanings into a single "value"
cell -- the conceptual simplicity has been forfeited, and since "function
cell" and "value cell" machinery are isomorphic, there is virtually no
coding advantage remaining.
FUNCALL/APPLY* have been around "since antiquity" to make the exceptions
for function syntax, but VAX/NIL and current CommonLisp permit local
re-binding of function cells *** as an option; The Bobrow "general
expectation" is not violated in these systems. More recently, (i.e., post-1977)
there have been introduced declarations and/or constructs into Interlisp,
LispMachineLisp, VAX/NIL, and CommonLisp to supply the second exception
noted above, namely symbolic constants.
I have frequently offered the observation that this distinction is also
rooted in mathematical notation, where journals generally distinguish
function names from variable names by any of a number of devices:
such as, slant type-face vs perpendicular, boldface versus regular, or
conventional subsets of letters (e.g., "f" and "G" are clearly function
names, whereas "x" and "Y" are variable names). Curiously, I've heard
that there is a reversal of some of these conventions between the American
and the European publishers. Can anyone verify this?)
There seems also to be some confusion about the implementation status of
this "distinction", that variables are by default local. As far as I know,
this *is* true of all major Lisp implementations I've worked with. What
isn't true is that that the interpreters of said systems "do the right thing"
(as opposed to the compiled code environment, which defines the semantics).
Almost without exception, the interpreters implement **only** fluid
bindings. VAX/NIL had an interpreter that correctly implemented both
local and fluid variables (see my paper in the 1982 Lisp Conference for a
description of a non-consing scheme to do it). Many toy interpreters have
been built which implement distinctions, but do so by consing up the usual
old alist environment, or some equivalent thereof. Another interesting
interpreter which implements local variables was done prior to 1977 by the
group at IBM Research Center in Yorktown Heights (in Lisp/370), in which
the interpretation of a lambda application did a mini-compilation in order to
get *exactly* the same stack frame as would be built had the code been truly
compiled; the claim was that you wouldn't see differences between compiled
and interpreted code in Lisp/370.
More in defense of my conjecture above.:
Bobrow tells me that the first implementation of 940Lisp (the "root
stock" of BBN lisp) was with the function/variable "optimisation"
mentioned above. On a small computer, cramped for space, with
a one-man implementation team . . . but the user community
balked, and convinced the implementor to re-support the
mathmatically grounded distinction between function context
and value context. Major Lisp systems today have long passsed
the point where they are one-man projects, but happily haven't
reached OS syndrome yet (i.e., a system so big, with so many ad-hoc
extensions and patches, that no one even knows a complete subset
of people who collectively understand the system).
Several of the SCHEME-lovers have privately expressed the opinion to me
that the value of SCHEME is that it doesn't have a user community (except
for learners and tinkers), and thus *can* be kept super-simple and "clean".
David Warren, a principle implementor of PROLOG, also expressed (privately)
such an opinion, and will rue the day that the Japanese turn Prolog into
some kind operating system for 5th Generation hardware.
There will always be difference of viewpoint between those who want to
"muck around" with program semantics and small, "clean" systems, and
those who want a full complement of "power tools" for doing AI research
and applications program development.
∂27-Sep-83 1716 @USC-ECL:GJC@MIT-MC your note on Function Cells.
Received: from USC-ECL by SU-AI with TCP/SMTP; 27 Sep 83 17:15:18 PDT
Received: from MIT-MC by USC-ECL; Tue 27 Sep 83 17:13:28-PDT
Date: 27 September 1983 20:10 EDT
From: George J. Carrette <GJC @ MIT-MC>
Subject: your note on Function Cells.
To: JonL.pa @ PARC-MAXC
cc: LISP-FORUM @ MIT-MC, Padget @ UTAH-20
In-reply-to: Msg of Tue 27 Sep 83 16:16 PDT from JonL.pa at PARC-MAXC.ARPA
A loaded VAX-NIL MACSYMA has about 14 thousand of what you
call slink cells allocated, mostly for function cells. So if
you had implemented them as a slot in the symbol it would have
indeed been a loser. Actually, another thing the indirection
buys us is to make it possible to relocate symbols without putting
a lot of work into looking at compiled code or its support structures.
Another kind of function cell we see a lot of now is a
flavor-method-table entry. These also get a regular function
cell too now, for the purpose of "book-keeping" in the assembler/loader,
so the figure of 14 thousand is more than slightly bloated by this
and by procedures on property lists. The garbage collector can
clean up this garbage though if the loader did a MAKFUNBOUND.
As you pointed out, the multiple-namespace concept is a very useful
one, and one that programmers have to be able deal with.
People should know that real Scheme programmers can make use of the
multiple-namespace idea too. In Yale T or MIT "6.001 " scheme one
might do a few different things:
(putprop 'foo (lambda (...) ...) 'bar)
and then write
((get'foo'bar) ...)
or define something that looks cleaner and runs faster such as:
(define-namespace foo)
(define-in-namespace (foo bar) (lambda (...) ...))
and then write
((foo bar) ...)
The *hack* is that languages that are implemented efficiently enough
in *general* allow the user to add his own namespace concepts which will
run as fast as if the implementor had wired them into the system and
wrote about them in the manual himself.
I have observed that T, MIT SCHEME, VAX-NIL, and Lispmachine(s)
live up to this *hack*, requiring slightly different amounts of
kludgery on the part of the user in some cases, but with nothing at
the level of LAP or MICROCODE being required.
This puts the arguments on a totally different level, at least for
people with practical access to these kinds of languages/machines.
You can do an excelent implementation of maclisp namespacing in T,
and vice-versa (for the maclisp descendants such as lispm and nil).
On the other hand, architectural optimizations in hardware and/or
software can make it a real bitch (to use the techical term) to implement
tail-calling in some implementations.
-gjc
∂30-Sep-83 1202 @USC-ECL,@MIT-MC:GLR@MIT-OZ
Received: from USC-ECL by SU-AI with TCP/SMTP; 30 Sep 83 12:02:28 PDT
Received: from MIT-MC by USC-ECL; Fri 30 Sep 83 12:01:55-PDT
Date: Fri, 30 Sep 1983 14:38 EDT
Message-ID: <[MIT-OZ].GLR.30-Sep-83 14:38:42>
From: Jerry Roylance <GLR@MIT-OZ>
To: BUG-LISP@MIT-OZ
SETF (EVAL-ONCE) gets confused?
This works:
(setf (ldb ppss (arraycall fixnum array index)) val)
=> (store (arraycall fixnum array index)
(dpb val ppss (arraycall fixnum array index)))
But change val to a function call, and we start SETQ'ing gensyms
(setf (ldb ppss (arraycall fixnum array index)) (fcn))
=> (let ((g0001 (arraycall fixnum array index)))
(setq g0001
(dpb val ppss g0001)))
∂08-Nov-83 1944 @USC-ECL,@MIT-MC:Alan@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 8 Nov 83 19:44:24 PST
Received: from MIT-MC by USC-ECL; Tue 8 Nov 83 19:40:00-PST
Date: Tuesday, 8 November 1983, 18:41-EST
From: Alan Bawden <Alan at MIT-MC>
To: GLR at MIT-AI
Cc: Bug-Lisp at MIT-MC
In-reply-to: <GLR.11965860451.BABYL@MIT-OZ>
Date: Mon, 7 Nov 1983 22:14 EST
From: Jerry Roylance <GLR%MIT-OZ@MIT-MC.ARPA>
Hmm. Has MACLISP stopped looking in the connected directory
for init files? A lot of batch jobs stopped working.
Yup. We "fixed the bug" where MacLisp would look in your connected directory
rather than your home directory for your Lisp init file.
∂15-Nov-83 0035 @USC-ECL,@MIT-MC:Gumby@MIT-MC correction: ledit hook
Received: from USC-ECL by SU-AI with TCP/SMTP; 15 Nov 83 00:35:42 PST
Received: from MIT-MC by USC-ECL; Mon 14 Nov 83 23:28:22-PST
Date: Tuesday, 15 November 1983, 02:29-EST
From: David Vinayak Wallace <Gumby at MIT-MC>
Subject: correction: ledit hook
To: bug-lisp at MIT-MC
Attention: tops-20 ledit users
Correction: In order to be more consistent with other MACLISP
hooks, Ledit-return-hook (documented in a previous message)
should be a function of no arguments to be called when returning
to lisp.
So again, to clear your screen after exiting emacs, try
(setq ledit-return-hook '(lambda ()
(cursorpos 'c)))
david
∂16-Nov-83 0120 @USC-ECL:JPG@MIT-MC (TYO #\BS) in Tops20 Maclisp
Received: from USC-ECL by SU-AI with TCP/SMTP; 16 Nov 83 01:20:10 PST
Received: from MIT-MC by USC-ECL; Wed 16 Nov 83 01:19:01-PST
Date: 16 November 1983 04:22 EST
From: Jeffrey P. Golden <JPG @ MIT-MC>
Subject: (TYO #\BS) in Tops20 Maclisp
To: BUG-LISP @ MIT-MC
cc: JPG @ MIT-MC
Can someone help Acuff@RUTGERS? He's got an H19 terminal, if that
matters. Also, they don't have VTS.
Date: 16 Nov 83 00:37:10 EST
From: Rich Acuff at Ohio State <Acuff@RUTGERS.ARPA>
To: JPG@MIT-MC.ARPA
I've experimented with MACLISP here, and it seems to be a 'feature'
of TYO that it will 'emulate' a backspace character by doing a return,
and several spaces. The strange thing is that the BS character IS
output before the return-spaces. I can't find any documentation or
code for TYO here, so I couldn't check this out for sure. If you can
tell me where to find some documentation and code for TYO (presumably
in Midas), and how to load MACLISP's symbol table from Tops-20 DDT,
I'll get out of your hair.
∂16-Nov-83 1138 @USC-ECL:GJC@MIT-MC (TYO #\BS) in Tops20 Maclisp
Received: from USC-ECL by SU-AI with TCP/SMTP; 16 Nov 83 11:35:02 PST
Received: from MIT-MC by USC-ECL; Wed 16 Nov 83 11:33:24-PST
Date: 16 November 1983 14:27 EST
From: George J. Carrette <GJC @ MIT-MC>
Subject: (TYO #\BS) in Tops20 Maclisp
To: Acuff @ RUTGERS
cc: BUG-LISP @ MIT-MC, JPG @ MIT-MC
In-reply-to: Msg of 16 Nov 1983 04:22 EST from Jeffrey P. Golden <JPG>
There are a couple "terminal-handlers" for vanilla tops-20 maclisp
hanging around, the ones I know about are:
[1] one I installed at HP labs palo-alto in summer of 1982
[2] one used at YALE university.
[3] one JONL did at MIT.
These quite effectively do cursorpos and other operations once you
tell it what kind of terminal you have. The basic hack is that the
proper SSTATUS TTY call is done to put the terminal in image mode, and
then the values of TYI and TYO are bashed with an SFA which handles
all input and output. Then SSTATUS TTYSCAN is done to setup a
rubout-handler which will use the lisp-level cursorpos calls. At
least, that is how jonl's and my code worked. My code was
backtranslated from VAX-NIL => MACLISP. (The NIL code parses the Unix
"termcap" database by the way.)
This is all to say that you shouldn't expect the assembly-language
level code for terminal-handling in vanilla tops-20 to do anything
reasonable, your best bet is to get one of these packages which patch
things quite nicely at lisp-level.
-gjc
∂29-Nov-83 0022 @USC-ECL:KMP@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 29 Nov 83 00:21:44 PST
Received: from MIT-MC by USC-ECL; Tue 29 Nov 83 00:12:34-PST
Date: 29 November 1983 03:21 EST
From: Kent M Pitman <KMP @ MIT-MC>
To: BUG-LISP @ MIT-MC
For those who care, I added a function called TIME:PARSE-LIST to the
TIME library on LIBLSP. It's like TIME:PARSE on the LispM, but returns
a list of information rather than multiple values. See LIBDOC;TIME >
for details. The code is translated from my Teco time parser, so don't
expect to be able to read it... it looks more like Teco than like Lisp.
It may have some shortcomings, but it handles a lot of the useful cases
and should suffice for simple applications.
∂11-Dec-83 1737 @USC-ECL:KMP@MIT-MC SASW: use of ALLFILES
Received: from USC-ECL by SU-AI with TCP/SMTP; 11 Dec 83 17:37:43 PST
Received: from MIT-MC by USC-ECL; Sun 11 Dec 83 17:35:24-PST
Date: 11 December 1983 20:29 EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: SASW: use of ALLFILES
To: BUG-LISP @ MIT-MC
My guess is he wasn't reading current documentation. My manual
documents ALLFILES correctly. I sent him more detailed mail to this
effect. -kmp
∂15-Dec-83 2149 YM (on TTY1) BCOMPLR deleted files
To: BUG-ncomplr
I compiled a file with BCOMPLR using the command
FILE.LSP(fmt)
I got the message ((....)) compiled - 0 words
and then the file disappeared.
It happend to three files only one of them I managed to rescue using UNDEL
which identified BCOMPLR as the deleting program.
What makes it even stranges us that the file protection was 257 so I was
supposed to be asked before the file could be deleted.
This happend at the end of a long sequence of files that were compiled
succesfully followed by e file which missed a closing paren. Before
compiling the other files (those that were deleted) files i did ↑G and then
(maklap)
Thanks,
Yoni Malachi.
∂19-Dec-83 1429 @USC-ECL,@MIT-MC:YM@SU-AI BCOMPLR deleted files
Received: from USC-ECL by SU-AI with TCP/SMTP; 19 Dec 83 14:28:14 PST
Received: from MIT-MC by USC-ECL; Mon 19 Dec 83 14:24:24-PST
Date: 17 Dec 83 1316 PST
From: Yoni Malachi <YM@SU-AI>
Subject: BCOMPLR deleted files
To: BUG-LISP@MIT-MC
I compiled a file with BCOMPLR using the command
FILE.LSP(fmt)
I got the message ((....)) compiled - 0 words
and then the file disappeared.
It happend to three files only one of them I managed to rescue using UNDEL
which identified BCOMPLR as the deleting program.
What makes it even stranges us that the file protection was 257 so I was
supposed to be asked before the file could be deleted.
This happend at the end of a long sequence of files that were compiled
succesfully followed by e file which missed a closing paren. Before
compiling the other files (those that were deleted) files i did ↑G and then
(maklap)
Thanks,
Yoni Malachi.
∂03-Jan-84 1825 CJL%MIT-OZ%MIT-MC.ARPA@USC-ECL.ARPA Setf's of load-byte don't work - broken foo-byte-expander
Received: from USC-ECL by SU-AI with TCP/SMTP; 3 Jan 84 18:25:01 PST
Received: from MIT-MC by USC-ECL; Tue 3 Jan 84 18:18:02-PST
Date: Tue, 3 Jan 1984 21:15 EST
Message-ID: <CJL.11980791940.BABYL@MIT-OZ>
From: Chris Lindblad <CJL%MIT-OZ@MIT-MC.ARPA>
To: bug-lisp%MIT-OZ@MIT-MC.ARPA
Subject: Setf's of load-byte don't work - broken foo-byte-expander
The following function doesn't work when compiled.
Alan looked at it for a while, and says that foo-byte-expander
is broken.
(DEFUN MAKE-BYTEPOINTER (BYTE-SIZE ADDRESS BYTE-POSITION)
(LET ((BP 0.))
(SETF (LOAD-BYTE BP 0 18.) ADDRESS)
(SETF (LOAD-BYTE BP 24. 6.) BYTE-SIZE)
(SETF (LOAD-BYTE BP 30. 6.) BYTE-POSITION)
BP))
∂04-Jan-84 0848 JONL.PA%PARC-MAXC.ARPA@USC-ECL.ARPA Re: Setf's of load-byte don't work - broken foo-byte-expander
Received: from USC-ECL by SU-AI with TCP/SMTP; 4 Jan 84 08:48:31 PST
Received: from MIT-MC by USC-ECL; Wed 4 Jan 84 00:46:48-PST
Received: from MIT-MC by MIT-OZ via Chaosnet; 4 Jan 84 03:44-EST
Date: 4 JAN 84 00:39 PST
From: JONL.PA@PARC-MAXC.ARPA
Subject: Re: Setf's of load-byte don't work - broken foo-byte-expander
To: CJL%MIT-OZ@MC.ARPA, bug-lisp%MIT-OZ@MC.ARPA
cc: JONL.PA@PARC-MAXC.ARPA
In response to the message sent Tue, 3 Jan 84 21:15 EST from CJL%MIT-OZ@MIT-MC.ARPA
This is a long-standing bug. RWK promised to look at it in the fall of
1981, but never got around to it. The code for the setf expander is a
bit dense, and several others (myself included) elected not to spend a
great deal of time probing into it.
∂04-Jan-84 0849 JONL.PA%PARC-MAXC.ARPA@USC-ECL.ARPA Re: Setf's of load-byte don't work - broken foo-byte-expander
Received: from USC-ECL by SU-AI with TCP/SMTP; 4 Jan 84 08:49:01 PST
Received: from MIT-MC by USC-ECL; Wed 4 Jan 84 01:43:00-PST
Date: 4 JAN 84 01:08 PST
From: JONL.PA@PARC-MAXC.ARPA
Subject: Re: Setf's of load-byte don't work - broken foo-byte-expander
To: ALAN@MC.ARPA, JONL.PA@MC.ARPA
cc: CJL%MIT-OZ@MC.ARPA, bug-lisp@MC.ARPA, JONL.PA@PARC-MAXC.ARPA
In response to the message sent Wed, 4 Jan 84 04:04 EST from ALAN@MIT-MC.ARPA
Unless someone has fixed the DEFSETF for LOAD-BYTE, then he *will* have
a setf bug problem.
I thought GSB fixed the LOAD-BYTE optimizer about a year ago?
∂04-Jan-84 0849 ALAN%MIT-MC.ARPA@USC-ECL.ARPA Re: Setf's of load-byte don't work - broken foo-byte-expander
Received: from USC-ECL by SU-AI with TCP/SMTP; 4 Jan 84 08:48:47 PST
Delivery-Notice: While sending this message to SU-AI.ARPA, the
USC-ECL.ARPA mailer was obliged to send this message in 50-byte
individually Pushed segments because normal TCP stream transmission
timed out. This probably indicates a problem with the receiving TCP
or SMTP server. See your site's software support if you have any questions.
Received: from MIT-MC by USC-ECL; Wed 4 Jan 84 01:04:31-PST
Date: Wednesday, 4 January 1984, 04:04-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject: Re: Setf's of load-byte don't work - broken foo-byte-expander
To: JONL.PA at PARC-MAXC
Cc: CJL%MIT-OZ at MIT-MC, bug-lisp at MIT-MC
In-reply-to: The message of 4 Jan 84 03:39-EST from JONL.PA at PARC-MAXC
Date: 4 JAN 84 00:39 PST
From: JONL.PA@PARC-MAXC.ARPA
This is a long-standing bug. RWK promised to look at it in the fall of
1981, but never got around to it. The code for the setf expander is a
bit dense, and several others (myself included) elected not to spend a
great deal of time probing into it.
The problem hs nothing to do with SETF. The problem is that the optimizer on
LOAD-BYTE and DEPOSIT-BYTE is broken.
∂09-Jan-84 1137 @USC-ECL,@MIT-MC:MARTY%MIT-OZ@MIT-MC LOAD and pathnames
Received: from USC-ECL by SU-AI with TCP/SMTP; 9 Jan 84 11:36:46 PST
Received: from MIT-MC by USC-ECL; Mon 9 Jan 84 11:34:41-PST
Date: 9 Jan 1984 13:44 EST (Mon)
Message-ID: <MARTY.11982282652.BABYL@MIT-OZ>
From: Martin David Connor <MARTY%MIT-OZ@MIT-MC.ARPA>
To: Bug-Lisp@MIT-MC
Subject: LOAD and pathnames
Would someone fix this?
[PHOTO: Recording initiated Mon 9-Jan-84 1:39PM]
MIT TOPS-20 Command Processor 5(750)-2
!lisp ↑V
LISP 2141
Alloc? n
*
(load "ps:<gz.lisp>hostmap")
;(LOAD ((|ps| ||) |hostmap| LSP *)) FILE NOT FOUND
What happened to the directory name?
;BKPT IO-LOSSAGE
(load "<gz.lisp>hostmap")
Well, if I leave off the structure name. But come now.
;Loading HOSTMAP 24
122160
↑Z
!pop
[PHOTO: Recording terminated Mon 9-Jan-84 1:40PM]
∂24-Jan-84 1547 @USC-ECL:ALAN@MIT-MC The comment is not mine
Received: from USC-ECL by SU-AI with TCP/SMTP; 24 Jan 84 15:47:02 PST
Received: from MIT-MC by USC-ECL; Tue 24 Jan 84 15:10:48-PST
Date: 24 January 1984 18:10 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: The comment is not mine
To: DEVON @ MIT-MC
cc: BUG-COMPLR @ MIT-MC
In-reply-to: Msg of 01/24/84 08:58:06 from DEVON at MIT-ML
Date: 01/24/84 08:58:06
From: DEVON at MIT-ML
I get
MPV; 11607>>HRRZ 1,(1) 1/ 777000 777000/ ??
when I try :COMPLR USERS1;DEVON NUTRI on ML..
Because the DO in the following macro is mal-formed:
(defmacro ask-cond (subject . choices)
(let ((questions (mapcar #'car choices))
(actions (do ((n 1 (1+ n)) ;RMS's pine goise: }I{
action
actions)
((null choices)
actions)
(setq action (cdar choices))
(setq choices (cdr choices))
(push (cons n action) actions))))
`(caseq
(ask-cond-really ,subject ',questions)
,@actions)))
If you had tried running this code interpreted you would have found the
problem yourself.
∂24-Jan-84 1751 @USC-ECL:DEVON@MIT-MC The comment is not mine
Received: from USC-ECL by SU-AI with TCP/SMTP; 24 Jan 84 17:44:01 PST
Received: from MIT-MC by USC-ECL; Tue 24 Jan 84 17:40:48-PST
Date: 24 January 1984 20:40 EST
From: Devon S. McCullough <DEVON @ MIT-MC>
Subject: The comment is not mine
To: ALAN @ MIT-MC
cc: BUG-COMPLR @ MIT-MC
In-reply-to: Msg of 24 Jan 1984 18:10 EST from Alan Bawden <ALAN @ MIT-MC>
Date: 24 January 1984 18:10 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: The comment is not mine
To: DEVON @ MIT-MC
cc: BUG-COMPLR @ MIT-MC
In-reply-to: Msg of 01/24/84 08:58:06 from DEVON at MIT-ML
Date: 01/24/84 08:58:06
From: DEVON at MIT-ML
I get
MPV; 11607>>HRRZ 1,(1) 1/ 777000 777000/ ??
when I try :COMPLR USERS1;DEVON NUTRI on ML..
Because the DO in the following macro is mal-formed:
(defmacro ask-cond (subject . choices)
(let ((questions (mapcar #'car choices))
(actions (do ((n 1 (1+ n)) ;RMS's pine goise: }I{
action
actions)
((null choices)
actions)
(setq action (cdar choices))
(setq choices (cdr choices))
(push (cons n action) actions))))
`(caseq
(ask-cond-really ,subject ',questions)
,@actions)))
If you had tried running this code interpreted you would have found the
problem yourself.
The code works perfectly in the interpreter. I tried it again just to
make sure. The cryptic comment contains some actual line noise
generated when RMS picked up the phone, which I preserved for posterity.
∂24-Jan-84 1850 @USC-ECL,@MIT-MC:PGS@MIT-OZ yech
Received: from USC-ECL by SU-AI with TCP/SMTP; 24 Jan 84 18:50:28 PST
Received: from MIT-MC by USC-ECL; Tue 24 Jan 84 18:49:54-PST
Date: Tue, 24 Jan 1984 21:49 EST
Message-ID: <PGS.11986303168.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To: "Devon S. McCullough" <DEVON@MIT-MC>
Cc: ALAN@MIT-MC, BUG-COMPLR@MIT-MC
Subject: yech
In-reply-to: Msg of 24 Jan 1984 20:40-EST from Devon S. McCullough <DEVON at MIT-MC>
Date: Tuesday, 24 January 1984 20:40-EST
From: Devon S. McCullough <DEVON at MIT-MC>
(defmacro ask-cond (subject . choices)
(let ((questions (mapcar #'car choices))
(actions (do ((n 1 (1+ n))
action
actions)
((null choices)
actions)
(setq action (cdar choices))
(setq choices (cdr choices))
(push (cons n action) actions))))
`(caseq
(ask-cond-really ,subject ',questions)
,@actions)))
The code works perfectly in the interpreter. I tried it again just to
make sure...
By some sad coincidence DO loops of this form seem to work interpreted in
Maclisp, but it isn't because they should. The index variable specifiers
"action" and "actions" should be parenthesized.
∂31-Jan-84 1359 @USC-ECL,@MIT-MC:CJL@MIT-OZ (STATUS TTYSIZE) is broken for lengths and widths > 127. on TWENEX
Received: from USC-ECL by SU-AI with TCP/SMTP; 31 Jan 84 13:59:02 PST
Received: from MIT-MC by USC-ECL; Tue 31 Jan 84 13:58:37-PST
Date: Tue, 31 Jan 1984 16:57 EST
Message-ID: <CJL.11988085006.BABYL@MIT-OZ>
From: CJL%MIT-OZ@MIT-MC.ARPA
To: BUG-MACLISP%MIT-OZ@MIT-MC.ARPA
Subject: (STATUS TTYSIZE) is broken for lengths and widths > 127. on TWENEX
(STATUS TTYSIZE) returns the wrong numbers for terminal lengths and
widths greater than 127. on TWENEX. I suspect that this is because it
uses TT%LEN and TT%WID of the JFN mode word. These fields are only seven
bits. A better way to get the length and width of the terminal is to use
the .MORLL and .MORLW codes with MOTPR%. They return the values as full
36. bit words.
∂06-Feb-84 0906 DEVON%MIT-MC.ARPA@USC-ECL.ARPA is it or isn't it a COMPLR bug?
Received: from USC-ECL by SU-AI with TCP/SMTP; 6 Feb 84 09:06:39 PST
Received: from MIT-MC by USC-ECL; Sat 4 Feb 84 21:45:44-PST
Date: 5 February 1984 00:45 EST
From: Devon S. McCullough <DEVON @ MIT-MC>
Subject: is it or isn't it a COMPLR bug?
To: BUG-LISP @ MIT-MC
cc: REM @ MIT-MC
Alan, try this and see for yourself that it works fine in both the
interpreter and the compiler. Maybe you have stylistic objections to
to the way I define the local iteration variable L in the loop, but
that's a matter of taste.
The macro merely expands to NIL, but if you now add the expression
(DO-MAC) to the end of the file and try to compile it then you get a
MPV in the compiler. I'm not complaining, nor trying to give you a
hard time! I just think it's a neat bug, I'm curious about how the
compiler works, but it's beyond me to figure this one out by myself.
If I'm missing something that's screamingly obvious to you, please
enlighten me.
; -*- Lisp -*-
(defun do-fun ()
(do ((n 1 (1+ n))
l)
((> n 7))
(setq l (cons '* l))
(print n)
(princ l)))
(defmacro do-mac ()
(do ((n 1 (1+ n))
l)
((> n 7))
(setq l (cons '* l))
(print n)
(princ l)))
∂06-Feb-84 0935 ALAN%MIT-MC.ARPA@USC-ECL.ARPA is it or isn't it a COMPLR bug?
Received: from USC-ECL by SU-AI with TCP/SMTP; 6 Feb 84 09:35:04 PST
Received: from MIT-MC by USC-ECL; Sun 5 Feb 84 15:17:23-PST
Date: 5 February 1984 16:43 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: is it or isn't it a COMPLR bug?
To: DEVON @ MIT-MC
cc: BUG-LISP @ MIT-MC, REM @ MIT-MC
In-reply-to: Msg of 5 Feb 1984 00:45 EST from Devon S. McCullough <DEVON>
Date: 5 February 1984 00:45 EST
From: Devon S. McCullough <DEVON>
Alan, try this and see for yourself that it works fine in both the
interpreter and the compiler. ...
Ok, I tried it and I got:
(do-fun)
1 (*)
;LJOB-EXPAND-RUN-MACRO UNBOUND VARIABLE
;BKPT UNBOUND-VARIABLE
If that confuses you, look at the property list of the symbol L in my lisp
environment:
(plist 'l)
(MACRO LJOB-EXPAND-RUN-MACRO)
The interpreter is blindingly taking the CDR of the symbol L. It's a bug
in the INTERPRETER. The fact that you seem to be able to compile such DOs
is totally orthogonal. Since macros are run INTERPRETED inside the
compiler, you sometimes get bit there.
Maybe you have stylistic objections to to the way I define the local
iteration variable L in the loop, but that's a matter of taste.
I have no stylistic objections. I'm just trying to tell you that it
doesn't work. This was not originally a feature of MacLisp DO, and someone
seems to have made an attempt to support it, but he blew it. Must I drop
everything and fix it immediately for you? Will it kill you to insert a
couple of extra parens into your DO?
∂08-Feb-84 0141 @USC-ECL.ARPA,@MIT-MC:JonL.pa@PARC-MAXC DO: an interpreter bug
Received: from USC-ECL by SU-AI with TCP/SMTP; 8 Feb 84 01:41:43 PST
Received: from MIT-MC by USC-ECL; Wed 8 Feb 84 01:38:48-PST
Date: 8 Feb 84 01:35 PST
From: JonL.pa@PARC-MAXC.ARPA
Subject: DO: an interpreter bug
To: Devon@MC.ARPA, Alan@MC.ARPA
cc: Bug-Lisp@MC.ARPA, REM@MC.ARPA
Hey, fellows, cool it. The COMPLR is correct. The original 1974 MacLisp
manual makes no mention of non-lists in the var-inits lists, but this
seems to have been a standard feature of MacLisp-like lisps since before
1980.
I don't know if anyone tried to fix the interpreter's version of DO --
quite likely no pdp10 MacLisp user depended on the extended syntax -- but
I wouldn't be suprised if someone reported this interpreter bug years ago.
The question is, "Who wants to fix it"?
∂08-Feb-84 1350 @USC-ECL.ARPA:WGD@MIT-MC DO: an interpreter bug
Received: from USC-ECL by SU-AI with TCP/SMTP; 8 Feb 84 13:50:43 PST
Received: from MIT-MC by USC-ECL; Wed 8 Feb 84 10:58:55-PST
Date: 8 February 1984 13:55 EST
From: William G. Dubuque <WGD @ MIT-MC>
Sender: BIL @ MIT-MC
Subject: DO: an interpreter bug
To: JonL.pa @ PARC-MAXC
cc: ALAN @ MIT-MC, BUG-LISP @ MIT-MC, DEVON @ MIT-MC, REM @ MIT-MC,
KMP @ MIT-MC
In-reply-to: Msg of 8 Feb 84 01:35 PST from JonL.pa at PARC-MAXC.ARPA
Well I've been screwed by this bug a number of times (I used to like
to distinguish between the case when a local binding is initially
undefined and when it is NIL, so I would write
(let ((some-list) undef)...)
to mean that SOME-LIST should be thought of as initially NIL
and that UNDEF's initial binding is undefined. Note that this
is a syntactic specification of a semantic distinction. I usually
utilized this distinction when it was important to emphasize the
fact that subsequent code depended upon certain initializations.
[I have since abandoned this scheme for other reasons]
This bug can often lead to rather obscure errors when the
interpreter starts marching down property lists. For this
reason, I would think that the small amount of time
necessary to remedy this simple problem would be well worth
the effort. There should probably be a suitable warning
regarding this problem in the Pitmanual.
∂08-Feb-84 1429 @USC-ECL.ARPA:ALAN@MIT-MC DO: an interpreter bug
Received: from USC-ECL by SU-AI with TCP/SMTP; 8 Feb 84 14:29:12 PST
Received: from MIT-MC by USC-ECL; Wed 8 Feb 84 14:27:47-PST
Date: 8 February 1984 16:57 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: DO: an interpreter bug
To: BUG-LISP @ MIT-MC, DEVON @ MIT-MC, KMP @ MIT-MC, REM @ MIT-MC,
WGD @ MIT-MC, JonL.pa @ PARC-MAXC
In-reply-to: Msg of 8 Feb 1984 13:55 EST from William G. Dubuque <WGD>
OK, OK, OK. I fixed it in the source and patched it in the XLISP on MC.
∂10-Feb-84 1041 @USC-ECL.ARPA:ALAN@MIT-MC MSGFILES, Heralds
Received: from USC-ECL by SU-AI with TCP/SMTP; 10 Feb 84 10:41:10 PST
Received: from MIT-MC by USC-ECL; Fri 10 Feb 84 10:39:23-PST
Date: 10 February 1984 13:37 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: MSGFILES, Heralds
To: GLR @ MIT-OZ
cc: BUG-LISP @ MIT-MC, BUG-MACLISP-MANUAL @ MIT-MC
In-reply-to: Msg of Fri 10 Feb 1984 12:13 EST from Jerry Roylance <GLR%MIT-OZ at MIT-MC.ARPA>
Date: Fri, 10 Feb 1984 12:13 EST
From: Jerry Roylance <GLR at OZ>
The messages
;Loading LET
; Loading FORMAT
should be directed to MSGFILES, not T.
They are as far as I can tell, can you demonstrate a way to get them to go
elsewhere?
Or is there some other way of turning them off?
There is. Do (SSTATUS FEATURE NOLDMSG).
Bug-MacLisp-Manual: (SSTATUS FEATURE NOLDMSG) isn't documented. In fact,
the existence of load messages isn't documented as far as I can tell.
∂10-Feb-84 1916 @USC-ECL.ARPA:KMP@MIT-MC MSGFILES, Heralds
Received: from USC-ECL by SU-AI with TCP/SMTP; 10 Feb 84 19:16:40 PST
Received: from MIT-MC by USC-ECL; Fri 10 Feb 84 19:15:35-PST
Date: 10 February 1984 22:14 EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: MSGFILES, Heralds
To: ALAN @ MIT-MC
cc: BUG-LISP @ MIT-MC, BUG-MACLISP-MANUAL @ MIT-MC, GLR @ MIT-OZ
References:
Msg of Fri 10 Feb 1984 12:13 EST from Jerry Roylance <GLR at MIT-OZ>
In-reply-to: Msg of 10 Feb 1984 13:37 EST from Alan Bawden <ALAN>
Date: 10 February 1984 13:37 EST
From: Alan Bawden <ALAN>
Date: Fri, 10 Feb 1984 12:13 EST
From: Jerry Roylance <GLR at OZ>
The messages
;Loading LET
; Loading FORMAT
should be directed to MSGFILES, not T.
They are as far as I can tell, can you demonstrate a way to get them to go
elsewhere?
Heh, heh. I bet I know what he did. I'm surprised you didn't figure it
out, Alan. This is a very standard bug -- almost as common as radix confusion,
I'd guess. If MSGFILES is non-NIL, then indeed the messages will go to
MSGFILES, -BUT- there is a slight bug in the implementation:
(TERPRI MSGFILES)
(PRINC ";Loading FOO 37" MSGFILES)
does the wrong thing when MSGFILES is NIL. An arg of NIL to TERPRI and PRINC
means to use the default destinations. These forms should really be conditional
on MSGFILES as well as (NOT (STATUS FEATURE NOLDMSG)).
Or is there some other way of turning them off?
There is. Do (SSTATUS FEATURE NOLDMSG).
Bug-MacLisp-Manual: (SSTATUS FEATURE NOLDMSG) isn't documented. In fact,
the existence of load messages isn't documented as far as I can tell.
Fixed in several places in the source.
∂15-Feb-84 0639 @USC-ECL.ARPA,@MIT-MC:SAE-ADA@USC-ECLB Addition to list
Received: from USC-ECL by SU-AI with TCP/SMTP; 15 Feb 84 06:39:41 PST
Received: from MIT-MC by USC-ECL; Wed 15 Feb 84 06:35:46-PST
Date: 15 Feb 1984 06:24-PST
Sender: SAE-ADA@USC-ECLB
Subject: Addition to list
From: SAE-ADA@USC-ECLB
To: lisp-forum@MIT-MC
Cc: sae-ada@USC-ECLB
Message-ID: <[USC-ECLB]15-Feb-84 06:24:09.SAE-ADA>
Just recently I saw a reference to this list in the Arpanet Franz
Friends list. Is it possible to join this list? If so, my address
is: CSNet debbie.kei-vax.umcp-cs at udel-relay
Arpanet sae-ada at usc-eclb
Please let me know when this will become effective.
Thank You
Debbie Franks
∂21-Feb-84 1928 @USC-ECL.ARPA,@MIT-MC:LAMPING@SU-SCORE Control Character I/O
Received: from USC-ECL by SU-AI with TCP/SMTP; 21 Feb 84 19:28:29 PST
Received: from MIT-MC by USC-ECL; Tue 21 Feb 84 19:25:55-PST
Date: Tue 21 Feb 84 19:22:05-PST
From: John Lamping <LAMPING@SU-SCORE.ARPA>
Subject: Control Character I/O
To: BUG-LISP@MIT-MC.ARPA
Could you tell me how to explain to TOPS-20 fromo MACLISP that I don't
want to do any special processing of control characters on input or
output. Especially, I would like to output escape sequences to my terminal
without TOPS-20 turning them into $'s.
Thank you!
-------
∂21-Feb-84 2054 @USC-ECL.ARPA,@MIT-MC,@CMU-CS-C:ZUBKOFF%TARTAN@CMU-CS-C Control Character I/O
Received: from USC-ECL by SU-AI with TCP/SMTP; 21 Feb 84 20:53:53 PST
Received: from MIT-MC by USC-ECL; Tue 21 Feb 84 20:51:33-PST
Received: from TARTAN by CMU-CS-C with TLnet; 21 Feb 84 23:30:09-EST
Received: ID <ZUBKOFF%TARTAN@CMU-CS-C.ARPA>; Tue 21 Feb 84 23:29:05-EST
Date: Tue, 21 Feb 1984 23:29 EST
From: Leonard N. Zubkoff <Zubkoff%TARTAN@CMU-CS-C.ARPA>
To: John Lamping <LAMPING@SU-SCORE.ARPA>
Cc: BUG-LISP@MIT-MC.ARPA
Subject: Control Character I/O
In-reply-to: Msg of Tue 21 Feb 84 19:22:05-PST from John Lamping <LAMPING at SU-SCORE.ARPA>
John,
You need to open the terminal in a special mode and then do your output to an
explicit file-object. For example,
(let ((image-tty (open 'Tty: '(out tty image single))))
(tyo #o33 image-tty)
...
(close Image-tty))
Leonard
∂22-Feb-84 0926 @USC-ECL.ARPA:KMP@MIT-MC Opening files locally
Received: from USC-ECL by SU-AI with TCP/SMTP; 22 Feb 84 09:26:19 PST
Received: from MIT-MC by USC-ECL; Wed 22 Feb 84 09:23:50-PST
Date: 22 February 1984 12:20-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: Opening files locally
To: Lamping @ SU-SCORE, Zubkoff%TARTAN @ CMU-CS-C
cc: BUG-LISP @ MIT-MC
In-reply-to: Msg of Tue 21 Feb 1984 23:29 EST from Leonard N. Zubkoff <Zubkoff%TARTAN at CMU-CS-C.ARPA>
Actually, rather than
(LET ((var (OPEN ...)))
...
(CLOSE var))
you want to use an UNWIND-PROTECT to make sure the file gets closed before
you lose your pointer to it. There are a couple of libraries with canned
versions of the appropriate UNWIND-PROTECT (which I don't recommend writing
yourself, since it's a lot of trouble to get right unless you've got a lot
of experience writing UNWIND-PROTECTs correctly). You might check out either
the IOTA macro (see the source to ((LIBLSP) IOTA) for documentation) or the
WITH-OPEN-FILE macro (see the source to ((LIBLSP) LISPM) for documentation).
-kmp
∂25-Feb-84 1424 @USC-ECL.ARPA,@MIT-MC:CS204.CASLEY@SU-SCORE Re: A Bug in Maclisp -- emacs?
Received: from USC-ECL by SU-AI with TCP/SMTP; 25 Feb 84 14:23:59 PST
Received: from MIT-MC by USC-ECL; Sat 25 Feb 84 14:22:10-PST
Date: Sat 25 Feb 84 14:20:22-PST
From: Ross Casley <CS204.CASLEY@SU-SCORE.ARPA>
Subject: Re: A Bug in Maclisp -- emacs?
To: GUMBY@MIT-MC.ARPA
cc: bug-lisp@MIT-MC.ARPA, crispin@SU-SCORE.ARPA
In-Reply-To: Message from "David Vinayak Wallace <GUMBY @ MIT-MC>" of Sat 25 Feb 84 12:22:00-PST
I do use ↑O/↑Q for page control while in LISP. ↑Q still works properly
while in EMACS. ↑O doesn't, and neither does ↑T. ↑T should interchange
two letters, but instead it gives the usage times, sytem load etc., the
same as if it were typed in a normal program. So neither ↑T nor ↑O ever
gets to EMACS. It looks like EMACS opens the terminal in the wrong mode
for some reason. The question is whether it is MACLISP which confuses
EMACS before it starts, or EMACS just gets confused because it is not
being run by the EXEC (or something), or the monitor is confused for
some reason and doesn't open the terminal in the mode which has been
requested.
None of these problems arise when using EMACS normally. Does anyone
know of another program which uses emacs the same way as maclisp?
Perhaps we could isolate the problem that way.
Ross.
-------
∂02-Mar-84 2104 @USC-ECL.ARPA,@MIT-MC:G.DAIR@SU-SCORE MACLISP availablity
Received: from USC-ECL by SU-AI with TCP/SMTP; 2 Mar 84 21:03:51 PST
Received: from MIT-MC by USC-ECL; Fri 2 Mar 84 21:01:16-PST
Date: Fri 2 Mar 84 20:58:19-PST
From: Willis Dair <G.Dair@SU-SCORE.ARPA>
Subject: MACLISP availablity
To: Bug-MACLISP@MIT-MC.ARPA
Phones: Work - (408) 984-4082; Home - (408) 923-BRIM
Address: Santa Clara Univ.; Kenna Comp. Ctr.; Santa Clara, Ca., 95053
I was referred to send mail to this address to find out how I can get
a TOPS-20 version of MACLISP. We at University of Santa Clara, Santa
Clara, Ca. are using MACLISP but there are pieces missing. Any info
as to how to acquire MACLISP for the -20 would be appreciated.
Thanks.
Willis
-------
∂11-Mar-84 1217 @USC-ECL.ARPA,@MIT-MC:MASINTER.PA@PARC-MAXC Backquote history
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 11 Mar 84 12:16:54 PST
Received: from MIT-MC by USC-ECL; Sun 11 Mar 84 11:52:56-PST
Date: 11 MAR 84 11:38 PST
From: MASINTER.PA@PARC-MAXC.ARPA
Subject: Backquote history
To: lisp-forum@mit-mc.ARPA
Anybody remember where backquote came from? I.e., who invented it, when
it got added to MacLisp, etc?
∂11-Mar-84 1240 @USC-ECL.ARPA:ALAN@MIT-MC Backquote history
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 11 Mar 84 12:40:33 PST
Received: from MIT-MC by USC-ECL; Sun 11 Mar 84 12:38:03-PST
Date: 11 March 1984 15:32-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Backquote history
To: MASINTER.PA @ PARC-MAXC
cc: LISP-FORUM @ MIT-MC
In-reply-to: Msg of 11 MAR 84 11:38 PST from MASINTER.PA at PARC-MAXC.ARPA
I think that most of what I know about backquote can be found in the file
LSPMAI;BACKQ XMAIL on MIT-MC. That file contains an extended discussion I
had with Drew McDermott about the history, philosophy and implementation of
bacquote.
∂11-Mar-84 1316 @USC-ECL.ARPA:KMP@MIT-MC Backquote history
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 11 Mar 84 13:16:13 PST
Received: from MIT-MC by USC-ECL; Sun 11 Mar 84 13:14:02-PST
Date: 11 March 1984 16:04-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: Backquote history
To: MASINTER.PA @ PARC-MAXC
cc: LISP-FORUM @ MIT-MC, Guy.Steele @ CMU-CS-A, McDermott @ YALE,
Genesereth @ SU-SCORE, Dick @ MIT-OZ, Hewitt @ MIT-OZ, GJS @ MIT-OZ
In-reply-to: Msg of 11 MAR 84 11:38 PST from MASINTER.PA at PARC-MAXC.ARPA
Date: 11 MAR 84 11:38 PST
From: MASINTER.PA at PARC-MAXC.ARPA
To: LISP-FORUM at MIT-MC.ARPA
Re: Backquote history
Anybody remember where backquote came from? I.e., who invented it,
when it got added to MacLisp, etc?
Seems like everyone and his brother had some sort of backquote.
It may be hard to come up with a single originator. The LispM
version predates the Maclisp version, so its presence in Maclisp
was probably most directly a compatibility measure; though at the
same time, obviously, a good idea in its own right. But the LispM
crowd probably didn't originate it either. It goes back farther
than I can remember (which would be 77 or so) anyway.
What is perhaps more interesting than who created it was the amount
of variety in these things. Here are some of the design decisions
that became involved ...
* There was a lot of variety in how , and ,@ things were marked. These
questions included what chars we could do without. eg, I was one of the
people making a lot of noise about "," not being whitespace any more,
so you couldn't write (5,3) to mean ordered pairs. In retrospect, this
didn't turn out to be much of a loss. Also, there was a question of
whether two char markers like ",@" and ",." were a good idea since
for example, (LAMBDA (X @X) `(FOO ,X ,@X ,@ X , @X)) could be visually
confusing. But it was a choice between two char markers and losing another
readmacro char, and no one wanted to give up yet another char.
* There was question about where copying should be allowed. ie,
if you did (DEFUN F (X) `(,X Y)) could you do (SETF (CADR (F ...)) ...)
on the result without affecting F's future behavior. Early versions
of backquote guaranteed copying, so `(A B C) was like (COPYTREE '(A B C)).
This was eventually decided to be a bad idea. The current backquote does
not define the sharing behavior; it tends to share structure where possible
but is not defined to do so.
* There was question about how nesting worked. In particular, some people
claimed that ,, type things should be disallowed. Others claimed that
you should do outside-in counting rather than inside-out. The current
behavior is inside-out. There was a long argument between Bawden, McDermott,
Steele, Rees, myself and a few others. If you're interested in that,
MC: LSPMAI; BACKQ XMAIL contains this discussion.
* There was also question about whether quoting or non-quoting should be
the default. Dick Waters had a variant where quoting was not the default.
Without seeing it, you might not guess the advantage, but the answer is
that you didn't have to write LIST, CONS, etc. eg, [X Y Z] was like
(LIST X Y Z), [X ! Y] was like (CONS X Y). There were advantages to this,
but basically it loses out when you start to look at large expressions
with little variability, since `(LAMBDA (,X Y) (+ ,X Y)) is almost the
same "shape" as the result it will produce, which is not true of
['LAMBDA [X] ['+ X 'Y]] which is not as visually similar to its result.
* I'm sure, though I can't recall specifically, there must have been heavy
controversy about whether destructive operations like ,. should be
allowed. I certainly don't like this one.
* There was also a question of what the backquote macro should read as.
It could either read directly as calls to LIST, CONS, etc. or it could
read as macros which would later expand to calls to LIST, etc. when
evaluted or compiled. According to the initial release notes, the first
version expanded at readtime, which of course meant that GRINDEF called
on such code gave a very verbose display. A switch, BACKQUOTE-EXPAND-WHEN,
was later added so that you could select EVAL or READ time expansion.
The default, EVAL, now allows GRINDEF to win on backquoted code.
* There were also some bogus arguments made like that we didn't need `
and ' to be different chars and that we should just let , be put in any
' expression. Such were beaten down by appeals to expressions like `',X
which are quite common.
On Sunday, 17-Sep-78, HIC and JONL announced backquote as an official
autoloading part of Lisp (version 1742).
On Thurday, 7-Jun-79, JONL announced the introduction of ",.", the
BACKQUOTE-EXPAND-WHEN feature, and the ability of GRINDEF to win on this
stuff.
I doubt the names of who announced these features are related to who came
up with them. Alan and I just tried to think of places where we
had seen backquote-like ideas; we came up with early versions of the
sources and/or sources to Scheme, LispM, PLASMA and Macsyma.
It was all a product of much negotiation among many people with similar
but subtly differing ideas.
∂12-Mar-84 0912 @USC-ECL.ARPA,@MIT-MC:acw@SCC-WAIKATO Backquote history
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 12 Mar 84 09:12:23 PST
Received: from MIT-MC by USC-ECL; Mon 12 Mar 84 09:10:08-PST
Received: from SCC-ROCKY by SCC-WAIKATO with CHAOS; Mon 12-Mar-84 12:10:35-EST
Date: Mon, 12 Mar 84 12:10 EST
From: "Allan C. Wechsler" <acw%SCC-WAIKATO@MIT-MC.ARPA>
Subject: Backquote history
To: MASINTER.PA@PARC-MAXC.ARPA, lisp-forum@MIT-MC.ARPA
In-reply-to: The message of 11 Mar 84 14:38-EST from MASINTER.PA at PARC-MAXC
I think the original ideas come from MDL. In MDL, lists and forms are
two different data types. Lists (written with parens) self-evaluate,
and forms (written with angle brackets) evaluate like forms do in Lisp.
(+ 2 3) => (1 2 3)
<+ 2 3> => 5
Then there is a weird mapping convention -- evaluation distributes over
lists.
(+ <+ 2 3> 5) => (+ 5 5)
There is a quote for those rare occasions where you don't want to
evaluate a form yet, but usually the things you would be quoting are
lists so you don't need the quote anyway.
Symbols self-evaluate in MDL -- you have to tell it you want the value
of a variable.
<SETG FOO 100> => 100
FOO => FOO
,FOO => 100
So you can imagine:
(4 ,FOO 5) => (4 100 5)
Finally, instead of comma-atsign they have exclamation:
<SETG FOO (1 2 3)> => (1 2 3)
(3 4 !,FOO 5) => (3 4 1 2 3 5)
(3 4 !<REST ,FOO> 5) => (3 4 2 3 5)
This stuff is sort of basic to MDL's evaluation philosophy, and they
have probably had it since their beginning in the early 70's.
Ref. "The MDL Programming Language", S.W. Galley and Greg Pfister,
1979, MIT Lab for Computer Science.
--- Allan
∂12-Mar-84 1043 @USC-ECL.ARPA:KMP@MIT-MC [GJS: Backquote history]
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 12 Mar 84 10:43:24 PST
Received: from MIT-MC by USC-ECL; Mon 12 Mar 84 10:40:10-PST
Date: 12 March 1984 13:18-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: [GJS: Backquote history]
To: LISP-FORUM @ MIT-MC
cc: Masinter.PA @ PARC-MAXC
References:
Msg of 12 Mar 84 12:10-EST from acw%SCC-WAIKATO @ MIT-MC.ARPA,
Msg of 11 Mar 84 18:37-PST from Gerald Jay Sussman <GJS @ CIT-20.ARPA>
Actually, it looks like it goes back farther than MDL...
Date: 11 Mar 1984 1837-PST
From: Gerald Jay Sussman <GJS at CIT-20.ARPA>
To: Kent M Pitman <KMP at MIT-MC.ARPA>
Re: Backquote history
In-Reply-To: Your message of 11 March 1984 16:04-EST
I remember a backquote-like idea being around when I was an undergraduate.
Adolpho Guzman and ?MacIntosh had a language called CONVERT (embedded in
Lisp) which had an un-quoting quotation FEXPR (These were the days before
there was even "'" syntax.). In addition, we had one in MicroPlanner, and
in Conniver (gotten from Guzman's idea). MUDDLE had the whole syntax
reversed to make that work out neatly.
I notice that the source to the Maclisp TRACE package has a macro called
QU* and which allows you to say things like
(QU* (... (EV ...) (EV* ...) ...))
where QU* is like "`", EV is like "," and "EV*" is like ",@". This may
be an example of the sort of "un-quoting quotation FEXPR" which GJS is
referring to.
For anyone interested in reading historical code, I recommend the functions
QU*, QU*1, and TRACE-1 (which uses QU*) in the file "MC: LSPSRC; TRACE >".
The file was last modified in 1981 and looks to have been "modernized" a
bit as it was modified, but most of its coding and even its grinding style
is much older. There is a modification history at the top of the file
detailing the origins of the code therein.
∂12-Mar-84 1237 @USC-ECL.ARPA:ALAN@MIT-MC Backquote history
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 12 Mar 84 12:37:17 PST
Received: from MIT-MC by USC-ECL; Mon 12 Mar 84 12:37:25-PST
Date: 12 March 1984 15:26-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Backquote history
To: ACW @ SCC-WAIKATO
cc: LISP-FORUM @ MIT-MC, MASINTER.PA @ PARC-MAXC
In-reply-to: Msg of Mon 12 Mar 84 12:10 EST from Allan C. Wechsler <acw%SCC-WAIKATO at MIT-MC.ARPA>
Mentioning MDL's list/form notation reminds me: anybody who is interested
in issues of quoting and quasi-quoting should definitely take a look at
Brian Smith's 3-LISP.
∂12-Mar-84 1311 @USC-ECL.ARPA,@MIT-MC:masinter.pa@PARC-MAXC Re: Backquote history
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 12 Mar 84 13:11:19 PST
Received: from MIT-MC by USC-ECL; Mon 12 Mar 84 13:11:32-PST
From: masinter.pa@PARC-MAXC.ARPA
Date: 11 Mar 84 16:36:21 PST
Subject: Re: Backquote history
In-reply-to: KMP@MIT-MC.ARPA's message of 11 Mar 84 16:04 EST
To: Kent M Pitman <KMP@MIT-MC.ARPA>
cc: MASINTER.pa@PARC-MAXC.ARPA, LISP-FORUM@MIT-MC.ARPA,
Guy.Steele@CMU-CS-A.ARPA, McDermott@YALE.ARPA,
Genesereth@SU-SCORE.ARPA, Dick@MIT-OZ.ARPA, Hewitt@MIT-OZ.ARPA,
GJS@MIT-OZ.ARPA
I'm glad to hear that we are not alone in having some arguments about
Backquote. There's been some back-and-forth about the Interlisp version,
with a variety of different opinions and implementations.
Recently, Warren Teitelman returned to me a document I had written in
1972 describing a number of features I had added to Lisp/360 at Stanford
in 1971 (with advice from Sridharan.)
Among the various packages was a backquote-like facility.
JonL had dismissed a number of my arguments as those of a "latecomer",
but he threw me out of his office when I suggested I might have even
INVENTED the idea.
It would be quite likely that this was something that Sridharan or I had
seen elsewhere, but it is also possible that this was something that
migrated out of Lisp/360, or that, being an obvious idea, it had arisen
spontaneously in a number of different contexts.
I was wondering if any of the examples you saw might pre-date 1972.
Larry
∂12-Mar-84 1447 @USC-ECL.ARPA,@MIT-MC:Mcdermott@YALE Backquote
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 12 Mar 84 14:46:50 PST
Received: from MIT-MC by USC-ECL; Mon 12 Mar 84 14:35:48-PST
Received: by YALE-BULLDOG via CHAOS; Mon, 12 Mar 84 17:25:29 EST
Date: Mon, 12 Mar 84 17:22:04 EST
From: Drew McDermott <Mcdermott@YALE.ARPA>
Subject: Backquote
To: kmp@MIT-MC.ARPA
Cc: MASINTER.pa@PARC-MAXC.ARPA, LISP-FORUM@MIT-MC.ARPA,
Guy.Steele@CMU-CS-A.ARPA, Mcdermott@YALE.ARPA,
Genesereth@SU-SCORE.ARPA, Dick%MIT-OZ@MIT-MC.ARPA,
Hewitt%MIT-OZ@MIT-MC.ARPA, GJS%MIT-OZ@MIT-MC.ARPA
As far as I know, Sussman and I invented backquote, around 1973,
as part of Conniver. However, we were inspired by
Planner/Muddle, which had the convention that lists evaluated to
lists of the values of their elements; function calls were
indicated by angle brackets. Furthermore, symbols evaluated to
themselves, too. You had to say ".var" to get the value of var.
Hence what would traditionally be indicated by
(LIST 'A X (+ I 1))
was in Planner/Muddle written
(A .X <+ I 1>)
We wrote this as
!"(A @X @(+ I 1))
(See pp. 85-86 of the Conniver Reference Manual, AI Memo 259a.)
Sussman later changed !" to ` (prettier and essential once
strings existed), and made it copy as much as possible of its
input (so it was just as efficient as ordinary quote). (He also
changed "@" to ","; in the original, ,X meant the Conniver value
of X, while @X meant the Lisp value.)
The original Planner/Muddle notation was due to Carl Hewitt and
Chris Reeve.
-------
∂12-Mar-84 2027 @USC-ECL.ARPA,@MIT-MC:JONL.PA@PARC-MAXC History of "backquote" macro
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 12 Mar 84 20:27:07 PST
Received: from MIT-MC by USC-ECL; Mon 12 Mar 84 20:24:44-PST
Date: 12 MAR 84 19:49 PST
From: JONL.PA@PARC-MAXC.ARPA
Subject: History of "backquote" macro
To: kmp@mit-mc.ARPA, Lisp-Forum@mc.ARPA
cc: McDermott@Yale.ARPA, Guy.Steele@cmuc.ARPA, Dick%MIT-OZ@mc.ARPA,,
Hewitt@mc.ARPA, gjs@mc.ARPA, Genesereth@Score.ARPA,
Masinter.PA@PARC-MAXC.ARPA, JonL.PA@PARC-MAXC.ARPA
In response to your message sent Mon, 12 Mar 84
There are two rather distinct components to the MacLisp-Style backquote,
which may have had varying influences from "history".
1) the notion of a template into which somethings were substituted existed
since the time of Adolfo Guzman's thesis around 1967-8; he had Lisp-level
macros called QU and QU* which were essentially like QUOTE except that the
form was "looked at" by a substitution parser, which substituted for certain
key words (i.e., the equivalent of "," and ",@"). In later years (meaning
around the time of Muddle -- 1971-75) some people were using variants of
a macro-defining function that incorporated similar ideas. Steele's
MACRODEF comes to mind and so does a similar package attributed to Chuck
Rich (both seem to have influenced DEFMACRO as well).
2) the notion of a reader macro that would "compile such a template on the
fly into Lisp code". I vaguely remember the influence of Muddle, especially
for "[" like constructs so that you didn't need to type LIST, (and such
a macro has been an essential feature of BRANDX for a long time, but with
more serious development). Such a reader macro wasn't in common use
at the MIT AI lab in 1975, but after I returned from IBM (roughly, Jan 1978)
I remember seeing the LispMachine people using it. We quickly recognized
its usefulness, and began a parallel development for PDP-10 MacLisp and NIL.
In fact, the "backquote" reader macro and DEFMACRO are so intertwined
that it has often been said that one can't understand backquote until he's
personally written a bunch of macro-producing macros using the ",'," and ",,"
paradigms.
The Post-1978 development as you (KMP) outlined in your note is more-or-less
as I remember it too.
∂24-Mar-84 1304 @USC-ECL.ARPA,@MIT-MC:ROBOT.GML@MIT-OZ
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 24 Mar 84 13:04:06 PST
Received: from MIT-MC by USC-ECL; Sat 24 Mar 84 13:02:52-PST
Date: Sat, 24 Mar 1984 15:57 EST
Message-ID: <ROBOT.GML.12001967680.BABYL@MIT-OZ>
From: ROBOT.GML%MIT-OZ@MIT-MC.ARPA
To: bug-lisp%MIT-OZ@MIT-MC.ARPA
When this little bit of code is run,
(defun testr (a b list1 list2)
(let ((list3 '(x y)))
(cond-every ((< a b) (nconc list3 list2))
((> a b) (nconc list3 list1))
(t list3))))
with a<b you get:
(x y <list2>) the first time
and
(x y <list2> <list2'>) the second time
and
(x y <list2> <list2'> <list2''> the third time.
etc.
it doesn't matter that you keep changing the parameters, it still
comes out larger each time.
∂24-Mar-84 1526 @USC-ECL.ARPA:ALAN@MIT-MC NCONC vs. APPEND
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 24 Mar 84 15:26:05 PST
Received: from MIT-MC by USC-ECL; Sat 24 Mar 84 15:22:17-PST
Date: 24 March 1984 18:20-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: NCONC vs. APPEND
To: ROBOT.GML @ MIT-OZ
cc: BUG-LISP @ MIT-MC
In-reply-to: Msg of Sat 24 Mar 1984 15:57 EST from ROBOT.GML%MIT-OZ at MIT-MC.ARPA
Date: Sat, 24 Mar 1984 15:57 EST
From: ROBOT.GML%MIT-OZ at MIT-MC.ARPA
(defun testr (a b list1 list2)
(let ((list3 '(x y)))
(cond-every ((< a b) (nconc list3 list2))
((> a b) (nconc list3 list1))
(t list3))))
... it doesn't matter that you keep changing the parameters, it still
comes out larger each time.
Since NCONC is defined to mutate its first argument, this is entirely
correct and expected behavior. If you had done (GRINDEF TESTR) after
calling it a couple of times, you would have found that it now looked
something like:
(defun testr (a b list1 list2)
(let ((list3 '(x y foo bar baz)))
(cond-every ((< a b) (nconc list3 list2))
((> a b) (nconc list3 list1))
(t list3))))
Moral: don't mutate the constants in your code.
Perhaps you should be using APPEND?
∂28-Mar-84 0930 @USC-ECL.ARPA:JGA@MIT-MC Mac-Lisp
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 28 Mar 84 09:30:42 PST
Received: from MIT-MC by USC-ECL; Wed 28 Mar 84 09:27:42-PST
Date: 28 March 1984 12:25-EST
From: John G. Aspinall <JGA @ MIT-MC>
Subject: Mac-Lisp
To: BUG-MACLISP @ MIT-MC
Is "Maclisp" copyrighted or a registered trademark? Seems to me that
it would be the number one choice of name for an Apple Macintosh lisp.
Maybe LCS could make a few bucks by licensing the name?
∂29-Mar-84 0932 @USC-ECL.ARPA:GUMBY@MIT-MC Mac-Lisp
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 29 Mar 84 09:32:45 PST
Received: from MIT-MC by USC-ECL; Thu 29 Mar 84 09:30:05-PST
Date: 29 March 1984 12:18-EST
From: David Vinayak Wallace <GUMBY @ MIT-MC>
Subject: Mac-Lisp
To: JGA @ MIT-MC
cc: BUG-MACLISP @ MIT-MC
In-reply-to: Msg of 28 Mar 1984 12:25-EST from John G. Aspinall <JGA>
Date: 28 March 1984 12:25-EST
From: John G. Aspinall <JGA>
Is "Maclisp" copyrighted or a registered trademark? Seems to me that
it would be the number one choice of name for an Apple Macintosh lisp.
Maybe LCS could make a few bucks by licensing the name?
Please look into it.
∂04-Apr-84 1045 @USC-ECL.ARPA:JGA@MIT-MC How intelligent is the complr?
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 4 Apr 84 10:45:12 PST
Received: from MIT-MC by USC-ECL; Wed 4 Apr 84 10:45:08-PST
Date: 4 April 1984 13:33-EST
From: John G. Aspinall <JGA @ MIT-MC>
Subject: How intelligent is the complr?
To: BUG-LISP @ MIT-MC
I need a null function or functions that just fill a temporary hole.
I need them with 0, 1 and 2 args. I would like them to be efficient.
Is
(defun nullfun (&rest nil) nil)
the better choice, or should I define 0, 1 and 2 arg versions
(defun nullfun0 () nil)
(defun nullfun1 (nil) nil)
(defun nullfun2 (nil nil) nil)
like so. Does the complr do the smart thing with the first choice?
When I compile the first version, I get a notice about an unused
variable called |Lexprvar...| in the unfasl file, but I don't read LAP
so I don't know whether that got into the machine code or not.
∂04-Apr-84 1158 @USC-ECL.ARPA:ALAN@MIT-MC How intelligent is the complr?
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 4 Apr 84 11:57:59 PST
Received: from MIT-MC by USC-ECL; Wed 4 Apr 84 11:57:52-PST
Date: 4 April 1984 14:53-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: How intelligent is the complr?
To: JGA @ MIT-MC
cc: BUG-LISP @ MIT-MC
In-reply-to: Msg of 4 Apr 1984 13:33-EST from John G. Aspinall <JGA>
Defining separate functions nullfun0, nullfun1, nullfun2 will result in the
fastest functions. The LEXPR calling convention will slow down the &REST
function.
∂04-Apr-84 1227 @USC-ECL.ARPA,@MIT-MC:JONL.PA@PARC-MAXC Re: How intelligent is the complr?
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 4 Apr 84 12:26:56 PST
Received: from MIT-MC by USC-ECL; Wed 4 Apr 84 12:24:36-PST
Date: 4 APR 84 12:13 PST
From: JONL.PA@PARC-MAXC.ARPA
Subject: Re: How intelligent is the complr?
To: ALAN@MC.ARPA, JGA@MC.ARPA
cc: BUG-LISP@MC.ARPA, JONL.PA@PARC-MAXC.ARPA
In response to the message sent 4 Apr 84 14:53 EST from ALAN@MIT-MC.ARPA
The slowdown for using an LEXPR may actually be unmeasurable -- there
will be a couple of extra instructions in the function, but since you
don't have a real &rest variable, there will be no consing up of an
arglist.
Why not try timing 10000 calls to each kind?
∂05-Apr-84 1531 @USC-ECL.ARPA:ALAN@MIT-MC How intelligent is the complr?
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 5 Apr 84 15:30:54 PST
Received: from MIT-MC by USC-ECL; Thu 5 Apr 84 15:26:51-PST
Date: 5 April 1984 17:42-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: How intelligent is the complr?
To: JONL.PA @ PARC-MAXC
cc: BUG-LISP @ MIT-MC, JGA @ MIT-MC
JGA and I both made measurements of the speed of the LEXPR overhead. It is
far from unmeasurable. My numbers show about a 40 microsecond penalty for
using the LEXPR calling convention. In the non-uuolink-snapped case
this makes calling a LEXPR about 50% more expensive.
You will understand why this is so if you recall that the .LCALL routine
that all LEXPRs JSP to to set themselves up, performs such book-keeping
operations including performing a pair of dynamic bindings, etc.
∂05-Apr-84 1620 @USC-ECL.ARPA,@MIT-MC:JONL.PA@PARC-MAXC Re: How intelligent is the complr?
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 5 Apr 84 16:20:19 PST
Received: from MIT-MC by USC-ECL; Thu 5 Apr 84 16:18:29-PST
Date: 5 APR 84 15:56 PST
From: JONL.PA@PARC-MAXC.ARPA
Subject: Re: How intelligent is the complr?
To: ALAN@MC.ARPA, JONL.PA@MC.ARPA
cc: BUG-LISP@MC.ARPA, JGA@MC.ARPA, JONL.PA@PARC-MAXC.ARPA
In response to the message sent 5 Apr 84 17:42 EST from ALAN@MIT-MC.ARPA
SIgh, 40 usecs is indeed large -- I'd hoped to see something more like
about 15 usecs on a KL10. Other possible out is, horrors, hand-coded LAP
which just adjust the PDL (using value from T) and then does POPJ P,
∂05-Apr-84 2232 @USC-ECL.ARPA,@MIT-MC:RWK@SCRC-YUKON How intelligent is the complr?
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 5 Apr 84 22:32:21 PST
Received: from MIT-MC by USC-ECL; Thu 5 Apr 84 22:30:48-PST
Received: from SCH-PECOS by SCH-GILA with CHAOS; Thu 5-Apr-84 09:41:23-PST
Date: Thu, 5 Apr 84 09:43 PST
From: "Robert W. Kerns" <RWK%SCRC-YUKON@MIT-MC.ARPA>
Subject: How intelligent is the complr?
To: "John G. Aspinall" <JGA@MIT-MC.ARPA>
Cc: BUG-LISP@MIT-MC.ARPA
In-reply-to: The message of 4 Apr 84 10:33-PST from John G. Aspinall <JGA at MIT-MC>
Message-ID: <840405094357.8.RWK@YUKON.SCRC.Symbolics>
Date: 4 April 1984 13:33-EST
From: John G. Aspinall <JGA @ MIT-MC>
I need a null function or functions that just fill a temporary hole.
I need them with 0, 1 and 2 args. I would like them to be efficient.
Is
(defun nullfun (&rest nil) nil)
the better choice, or should I define 0, 1 and 2 arg versions
(defun nullfun0 () nil)
(defun nullfun1 (nil) nil)
(defun nullfun2 (nil nil) nil)
like so. Does the complr do the smart thing with the first choice?
When I compile the first version, I get a notice about an unused
variable called |Lexprvar...| in the unfasl file, but I don't read LAP
so I don't know whether that got into the machine code or not.
Fixed-number-of-arguments functions (up to 5 arguments) use a more
efficient calling sequence. Therefore, your NULLFUNn functions will
be called more efficiently. Also, the generated code for a
variable-number-of-arguments function is substantially slower, but
this can be gotten around with a hand-coded function if really needed.
∂13-Apr-84 1142 REM (on TTY25) Bug in SPRIN1 here
To: BUG-PLISP
SPRIN1 goes into infinite loop, probably because of atom that won't
fit between margins. It should either print it randomly, or generate error.
∂29-Apr-84 2140 @USC-ECL.ARPA,@MIT-MC:cfry@MIT-OZ eval-while-possible
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 29 Apr 84 21:40:01 PDT
Received: from MIT-MC by USC-ECL; Sun 29 Apr 84 21:36:07-PDT
Received: from MIT-LISPM-4 by MIT-OZ via Chaosnet; 30 Apr 84 00:29-EDT
Date: Sunday, 29 April 1984, 23:30-EDT
From: Christopher Fry <cfry at MIT-OZ>
Subject: eval-while-possible
To: lisp-forum at MIT-OZ, lisp-forum-scrc at SCRC-TENEX
I've found the following function to be of general use when you're uncertain as to
how many evaluations are necessary, or just don't want to be bothered
in figuring it out. My own application for it is for a language
embedded in lisp, where the user is going to be calling functions in the language
with arguments that may be symbols, whose values are other expressions which should be
evaled, possibly more than once.
(defun eval-while-possible (expression &optional (instance nil) &aux values)
"Evals expression then evals the result of the previous evaluation, and so on
until error, or until evaluation returns a value eq to a previous value,
then returns the version of expression
just before the error.
If INSTANCE is non-nil, then each evaluation
is performed in the context of the instance. "
(setq values (list expression))
(loop do
(multiple-value-bind (the-value error?)
(ignore-errors
(cond (instance
(send instance :eval-inside-yourself (car values)))
(t (eval (car values)))))
(cond ((or error? (member the-value values))
(return (car values)))
(t (push the-value values))))))
∂30-Apr-84 1439 @USC-ECL.ARPA:GZ@MIT-MC DEFSTRUCT predicate option
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 30 Apr 84 14:38:54 PDT
Received: from MIT-MC by USC-ECL; Mon 30 Apr 84 14:36:04-PDT
Date: 30 April 1984 17:33-EST
From: Gail Zacharias <GZ @ MIT-MC>
Subject: DEFSTRUCT predicate option
To: BUG-LISP @ MIT-MC
If you use :predicate :eval-when (eval compile), the predicate gets
defined as as an expr at compile time only, which is pretty useless.
Any way to make it either be a macro or make it get compiled (i.e.
exempt it from the overall eval-when option)?
∂02-Jun-84 1057 @USC-ECL.ARPA:BMT@MIT-MC
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 2 Jun 84 10:57:15 PDT
Received: from MIT-MC by USC-ECL; Sat 2 Jun 84 10:56:21-PDT
Date: 2 June 1984 13:57-EDT
From: Barry M. Trager <BMT @ MIT-MC>
To: BUG-LISP @ MIT-MC
SUBST appears to have very strange semantics with respect to HUNKS.
It appears that hunks are not descended but they are top-level copied.
Is there some rationale for this behavior?
∂03-Jun-84 2126 @USC-ECL.ARPA:ALAN@MIT-MC Hunks
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 3 Jun 84 21:23:53 PDT
Received: from MIT-MC by USC-ECL; Sun 3 Jun 84 21:20:12-PDT
Date: 4 June 1984 00:15-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Hunks
To: BUG-MACLISP-MANUAL @ MIT-MC, BMT @ MIT-MC
cc: BUG-LISP @ MIT-MC
In-reply-to: Msg of 2 Jun 1984 13:57-EDT from Barry M. Trager <BMT>
Date: 2 June 1984 13:57-EDT
From: Barry M. Trager <BMT>
SUBST appears to have very strange semantics with respect to HUNKS.
It appears that hunks are not descended but they are top-level copied.
Is there some rationale for this behavior?
It was trying to descend them and do what you would expect, but there were
a couple of bugs standing in the way. I have fixed them in the source.
Bug-MacLisp-Manual: While poking around for background on this bug I
discovered a couple of inprovements that could be made in the manual:
1. The MAKHUNK function has a feature not ducumented in the manual. Given
a list instead of a number as an argument it creates a hunk whose elements
are taken from the list. (MAKHUNK (LIST A B C)) = (HUNK A B C).
2. The documentation for the HUNKP variable is a bit vague about just what
it effects. The complete story is that only three functions are affected:
EQUAL, PRINT, and PURCOPY. \Not/ SUBST as the documentation implies!
Additionally I discovered that EQUAL, PRINT, and PURCOPY are not consistent
about the order in which they check the STATUS USRHUNK function and the
value of HUNKP. Since the USRHUNK stuff has never been really documented
for users, and since changing the values of HUNKP (or the value of MAKHUNK)
is not recommended, this isn't really important. I just record it here for
posterity.
3. The "concept" entry for hunks points out that you can use the CXR 0
(CDR) of a hunk as a property list. This paragraph is a bit vague. I
presume you are trying to say that GET will use the CXR 0 of a hunk as if
it was a property list. If that is what you mean, then you should say so.
As written, the reader might well wonder why he couldn't keep a property
list in the CXR 7 slot if he wanted to.
∂04-Jun-84 1153 @USC-ECL.ARPA,@MIT-MC:REM@SU-AI Unnamed arrays not GC'd like they should.
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 4 Jun 84 11:52:47 PDT
Received: from MIT-MC by USC-ECL; Mon 4 Jun 84 11:47:47-PDT
Date: 04 Jun 84 1143 PDT
From: Robert Maas <REM@SU-AI.ARPA>
Subject: Unnamed arrays not GC'd like they should.
To: BUG-LISP@MIT-MC.ARPA
(This transcript collected at MIT-MC, 1984.June.04)
(Bug in GC, array words not reclaimed even though array no longer referenced.)
*:L
LISP 2138
Alloc? N
*
↑D
(GC)
;GC DUE TO USER
; 403[25%] LIST, 772[98%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 457[29%] SYMBOL, 756[96%] ARRAY WORDS FREE
;;Note that only 244 words of array are in use
NIL
(STATUS GCSIZE 'ARRAY)
0
(SSTATUS GCSIZE 'ARRAY 2000) ;;Forcing it to allocate more array space
T ;; before the next GC
(STATUS SPCSIZE 'ARRAY)
1000
(PROG () L (SETQ AA (ARRAY NIL T 5 5)) (PRINC ".") (GO L)).............!
............... ;;Gobbling up array cells and immediately
;; disgarding them. All arrays except the
;; very last should be reclaimed by GC.
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 3000 WORDS................!
.......................................................................!
.......................................................................!
.............................................................
;ADDING A NEW ARRAY SEGMENT -- ARRAY SPACE NOW 2000 WORDS..............!
....................... ;;GCSIZE working, allocated more space
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 4000 WORDS................!
.......................................................................!
.......................................................................!
............................................
;ADDING A NEW FIXNUM SEGMENT -- FIXNUM SPACE NOW 2000 WORDS............!
.....
;GC DUE TO LIST AND ARRAY SPACES
; 366[12%] LIST, 1764[98%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 452[29%] SYMBOL, 2[0%] ARRAY WORDS FREE
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 5000 WORDS
;ADDING A NEW ARRAY SEGMENT -- ARRAY SPACE NOW 3000 WORDS
;;Bug here, now that it thinks all 2000
;; words of array space are "in use" (pointed
;; at from somewhere else) when in fact
;; only the original 244 words plus the
;; very last (25-word plus header) SETQ'd
;; array should still be "in use".
;; There should be about 1750 array words free
;; instead of zero.
;BKPT GC-OVERFLOW
∂12-Jun-84 1855 @USC-ECL.ARPA:GSB@MIT-MC Unnamed arrays not GC'd like they should.
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 12 Jun 84 18:55:41 PDT
Received: from MIT-MC by USC-ECL; Tue 12 Jun 84 18:52:29-PDT
Date: 12 June 1984 21:45-EDT
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: Unnamed arrays not GC'd like they should.
To: REM @ SU-AI
cc: BUG-LISP @ MIT-MC
They get gc'ed, but not until the following gc. The consequence of
this is that arrays which reference themselves circularly do not
go away; however your example would have looped indefinitely if
you had proceeded the gc-overflow and it had upped the space a bit more.
∂16-Jun-84 1614 @USC-ECL.ARPA:ALAN@MIT-MC help in setting up LISP on PREP
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 16 Jun 84 16:13:28 PDT
Received: from MIT-MC by USC-ECL; Sat 16 Jun 84 15:02:50-PDT
Date: 16 June 1984 18:01-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: help in setting up LISP on PREP
To: DRogers @ MIT-OZ
cc: BUG-LISP @ MIT-MC
In-reply-to: Msg of Sat 16 Jun 84 17:08:19-EDT from David Rogers <DRogers%MIT-OZ at MIT-MC.ARPA>
Date: Sat 16 Jun 84 17:08:19-EDT
From: David Rogers <DRogers at OZ>
Anybody wish to help me set up a LISP on PREP so that is has all the nice
flavor and structure stuff? ...
Unfortunately, Bug-LISP deals only with MacLisp bugs and questions. You
might be lucky and hit somebody who knows about Franz anyway, but in
general you have come to the wrong place.
If I had to use a Lisp on a VMS Vax myself, I wouldn't go for Franz either,
I would use NIL. Have you considered that possibility? (Or perhaps you
are trying to bring up some code already written in Franz, or you have to
transport your work to a Franz later.)
BTW, when you get to bringing up the "structure stuff" please ignore my
name at the front of the defstruct file. The Franz people are distributing
that without my permission (they didn't even ASK me about it) and you
should therefore complain to anybody but me if you find problems.
∂16-Jun-84 1614 @USC-ECL.ARPA,@MIT-MC:DRogers@MIT-OZ help in setting up LISP on PREP
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 16 Jun 84 16:13:10 PDT
Received: from MIT-MC by USC-ECL; Sat 16 Jun 84 14:12:53-PDT
Date: Sat 16 Jun 84 17:08:19-EDT
From: David Rogers <DRogers%MIT-OZ@MIT-MC.ARPA>
Subject: help in setting up LISP on PREP
To: BUG-LISP%MIT-OZ@MIT-MC.ARPA
Anybody wish to help me set up a LISP on PREP so that is has all the nice
flavor and structure stuff? Or does anyone have any pointers? All aid
and advice would be greatly appreciated, as I am not well versed in
Franz-Lisp setup issues.
Thanks,
David
-------
∂28-Jul-84 1230 @USC-ECL.ARPA:ALAN@MIT-MC
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 28 Jul 84 12:30:00 PDT
Received: from MIT-MC by USC-ECL; Sat 28 Jul 84 12:23:05-PDT
Date: 28 July 1984 15:26-EDT
From: Alan Bawden <ALAN @ MIT-MC>
To: BUG-LISP @ MIT-MC
I don't recall if anyone has noticed this before, but I just noticed that
the EOFFN for a file being read using IN cannot return a value to the
caller. This is because IN is NCALLable, so the EOFFN would have to
arrange to return its value as a machine number in TT, rather than as an
object in A.
∂11-Sep-84 1228 @USC-ECL.ARPA,@MIT-MC:JonL.pa@Xerox [MJackson.Wbst: Why Your Pascal and Modula-2 Programs Don't
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 11 Sep 84 12:28:30 PDT
Received: from MIT-MC by USC-ECL; Tue 11 Sep 84 12:26:12-PDT
Received: from Semillon.ms by ArpaGateway.ms ; 11 SEP 84 12:17:57 PDT
Date: 11 Sep 84 12:17 PDT
From: JonL.pa@XEROX.ARPA
Subject: [MJackson.Wbst: Why Your Pascal and Modula-2 Programs Don't
Work]
To: Guy.Steele@CMU-CS-A.ARPA
cc: Bug-Lisp@MIT-MC.ARPA,Lisp-Forum@MIT-MC.ARPA,LispCore↑.pa@XEROX.ARPA
Reply-to: JonL.pa@XEROX.ARPA
The classic fencepost bug?
----- Begin Forwarded Messages -----
Date: Tue, 11 Sep 84 11:02 EDT
From: MJackson.Wbst
Subject: Why Your Pascal and Modula-2 Programs Don't Work
To: AllWhimsy↑.ES
cc: Modula-2↑.ES, ProcessTechnology↑
Reply-To: MJackson.Wbst
"In an array, individual elements are readily identified by means of a
computed index, which represents a position in the sequence of elements.
The address of the fifth element, for example, is simply the address of
the first element plus five times the size of an element."
-- Niklaus Wirth in the September /Scientific American/
----- End Forwarded Messages -----
∂13-Sep-84 2030 @USC-ECL.ARPA,@MIT-MC:BERWICK.PILATO@MIT-OZ
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 13 Sep 84 20:29:56 PDT
Received: from MIT-MC by USC-ECL; Thu 13 Sep 84 20:30:46-PDT
Date: Thu, 13 Sep 1984 23:27 EDT
Message-ID: <BERWICK.PILATO.12047389611.BABYL@MIT-OZ>
From: BERWICK.PILATO%MIT-OZ@MIT-MC.ARPA
To: bug-lisp%MIT-OZ@MIT-MC.ARPA
Dear anonymous aardvark,
Here is a Maclisp bug, unless I'm doing something wrong.
The problem is with pushing an item onto an array location when some
arguments are atomic and others aren't. Only the first evaluation of
the push form works, then an argument seems to get clobbered. The
interpreter fails, but not the compiler.
Please find enclosed some sample code that fails, some dribble, and other
debugging info that may be helpful.
;TEST.LOG
(load "test.lsp")(print (status lispversion))
/2141
(defun test ()
(do ((my-array (*array nil t 5))
(i 0 (1+ i)))
((> i 4))
(print (push 'a (arraycall t my-array (+ i 0))))))
T
(grindef test)
(DEFUN TEST NIL
(DO ((MY-ARRAY (*ARRAY NIL T 5)) (I 0 (1+ I)))
((> I 4))
(PRINT (PUSH 'A (ARRAYCALL T MY-ARRAY (+ I 0))))))
*
(test)
;Loading SETF 293
;Loading EXTSTR 96
;Loading MACAID 120
;Loading EVONCE 14
(A)
;|T..1| UNBOUND VARIABLE
;BKPT UNBND-VRBL
!
;debugging info -- the stack:
(+INTERNAL-UBV-BREAK ((|T..1|)))
|T..1|
(ARRAYCALL T MY-ARRAY |T..1|)
(CONS 'A (ARRAYCALL T MY-ARRAY |T..1|))
((LAMBDA (|T..5|) (STORE (ARRAYCALL T MY-ARRAY |T..1|) |T..5|))
(CONS 'A (ARRAYCALL T MY-ARRAY |T..1|)))
(PUSH 'A (ARRAYCALL T MY-ARRAY |T..1|))
(PRINT (PUSH 'A (ARRAYCALL T MY-ARRAY |T..1|)))
(DO ((MY-ARRAY (*ARRAY NIL T 5)) (I 0 (1+ I)))
((> I 4))
(PRINT (PUSH 'A (ARRAYCALL T MY-ARRAY |T..1|))))
(TEST)
QUIT
*
(grindef test)
(DEFUN TEST NIL
(DO ((MY-ARRAY (*ARRAY NIL T 5)) (I 0 (1+ I)))
((> I 4))
(PRINT (PUSH 'A (ARRAYCALL T MY-ARRAY |T..1|)))))
*
;compiling info:
;@complr test
;
;LISP COMPILER 1128 [in LISP 2140]
;
;Loading fix-up file |OZ:<MACLISP>CLFIX.1128.2|
;@
'(THIS IS THE UNFASL FOR ((OZ |BERWICK.PILATO|) TEST LSP /1))
'(ASSEMBLED BY FASLAP /392)
'(COMPILED BY LISP COMPILER /936 COMAUX /25 PHAS1 /86 MAKLAP /80 INITIA /120)
;COMPILED ON SEPTEMBER 12, 1984, AT 5:52 AM
(COMMENT **FASL** 0. (LAP TEST SUBR))
(COMMENT **FASL** TOTAL = 47. WORDS)
(load "test.fasl")
/2141
50726
(test)
(A)
(A)
(A)
(A)
(A)
NIL
∂24-Sep-84 1419 @USC-ECL.ARPA:KMP@MIT-MC m-F in LEDIT
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 14:19:35 PDT
Received: from MIT-MC by USC-ECL; Mon 24 Sep 84 14:11:05-PDT
Date: 23 September 1984 16:52-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Subject: m-F in LEDIT
To: Mellis @ MIT-EECS
cc: BUG-MACLISP @ MIT-MC
In-reply-to: Msg of Sun 23 Sep 1984 06:05 EDT from Adam G. Mellis <Mellis%MIT-EECS at MIT-MC.ARPA>
Date: Sun, 23 Sep 1984 06:05 EDT
From: Adam G. Mellis <Mellis%MIT-EECS at MIT-MC.ARPA>
According to <maclisp>ledit.doc, ↑R LEDIT Find Function is bound
to M-F, yet this function isn't in the ledit library (and M-F is
bound to ↑R Forward Word). What happened to M-F?
In fact, this is sort of an Emacs issue, not a Maclisp issue, but I
looked it up in the source to the Emacs LEDIT library anyway. The
answer is that ↑R LEDIT Find Function does not get put on any key.
Probably someone found that having meta-F not do the normal cursor
motion command was too confusing.
If you want it on a key, you should set it up yourself as a personal
customization in your EMACS.VARS file. I guess I recommend putting
it on some other key than m-F, though. Perhaps c-m-. would be a good
choice.
-kmp
∂24-Sep-84 1431 @USC-ECL.ARPA,@MIT-MC:EB@MIT-OZ cursorpos broken on batch jobs
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 14:31:04 PDT
Received: from MIT-MC by USC-ECL; Mon 24 Sep 84 14:26:04-PDT
Date: Sun 23 Sep 84 22:18-EDT
From: Ed Barton <EB%MIT-OZ@MIT-MC.ARPA>
Subject: cursorpos broken on batch jobs
To: bug-lisp@MIT-OZ
(CURSORPOS 'C) gives ;I/O ERROR DURING OUTPUT in a batch job.
Why doesn't it just return NIL? Is there any way to prevent
this error from happening every time I try to run a batch LISP
job that has a FORMAT ~| somewhere deep in the guts of the
program?
∂28-Sep-84 1437 @USC-ECL.ARPA,@MIT-MC:EB@MIT-OZ ferror
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 28 Sep 84 14:37:11 PDT
Received: from MIT-MC by USC-ECL; Fri 28 Sep 84 14:35:37-PDT
Date: Fri, 28 Sep 1984 15:45 EDT
Message-ID: <EB.12051237711.BABYL@MIT-OZ>
From: EB%MIT-OZ@MIT-MC.ARPA
To: Bug-Complr%MIT-OZ@MIT-MC.ARPA
Subject: ferror
In the COMPLR on Oz (Complr 1128, in Lisp 2140), FERROR has an
AUTOLOAD property of ((LISP) MLSUB FASL). That should be CERROR, not
MLSUB.
∂07-Oct-84 1408 @USC-ECL.ARPA:GZ@MIT-MC GETCOR
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 7 Oct 84 14:08:25 PDT
Received: from MIT-MC by USC-ECL; Sun 7 Oct 84 14:02:50-PDT
Date: 7 October 1984 16:59-EDT
From: Gail Zacharias <GZ @ MIT-MC>
Subject: GETCOR
To: BUG-LISP @ MIT-MC
How come GETCOR is not available on twenex? I.e. FASDFS defines it
under IFN ITS. But in the source it is under IFN PAGING, and it seems to
work ok in fact.
(It seems that just doing .GLOBAL GETCOR doesn't work, which is why I'm
reporting it... I guess it needs to be put in some table or something).
∂08-Oct-84 1113 @USC-ECL.ARPA,@MIT-MC:cpd@UCLA-LOCUS Benchmark - PERQ CL vs Apollo T
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 8 Oct 84 11:12:58 PDT
Received: from MIT-MC by USC-ECL; Mon 8 Oct 84 11:11:39-PDT
Date: Mon, 8 Oct 84 10:17:49 PDT
From: Charles Dolan <cpd@UCLA-LOCUS.ARPA>
To: T-Users@Yale, Lisp-Forum@MIT-MC, Common-Lisp@Su-AI
Subject: Benchmark - PERQ CL vs Apollo T
UCLA has a demo unit of the new PERQ 68000 based workstation
running Common Lisp. We are currently using Apollo workstations
and T. I compared the workstations on the following points:
standard shell startup,
standard editor startup,
lisp editor startup,
compilation,
(fact 100) - recursive factorial,
(tak 18 12 6) - code given below,
(reverse1 *long-list*) - recursive reverse of a 100
element list, and
(reverse2 *long-list*) - recursive reverse of a 100
element list using closures.
The DN300 is Apollo's low end workstation. It had 1.5 MB and no
local disk. The DN460 is Apollo's bit-slice implementation of the
68000 instruciton set.
PERQ DN300 DN460
shell 10 sec 2/5.5 sec [5] 1/3 sec [5]
editor 7 sec 1 sec 1 sec
lisp editor [1] 14/1.5 sec 23.3/3 sec 10.5/1.8 sec
compilation [4] 11 sec 54 sec 24 sec
(fact 100) 2.1 sec 1.12 sec 0.61 sec
(tak ...) [3] 6.3 sec 3.4/6.3 sec [2] 1/2.7 sec [2]
(reverse1 ...) 2.2 sec 1.2 sec 0.42 sec
(reverse2 ...) 2.7 sec 1.6 sec 0.67 sec
All times were computed by running the funciton is a loop 30
times and dividing the wall clock time by 30.
[1] Since the lisp editors are embedded in the lisp environment
two times are given. The first is for the initial startup of
the editor the first time it is invoked. The second is for
subsequent invocations.
[2] The faster of the two times times is for the case when block
complilation is used. Here the recursive calls to (tak ...)
are compiled as jumps.
[3] In the T code explicit calls to the FIXNUM arithmetic
routines 'FX<' and 'FX-' were used.
[4] The which was compiled is the code below plus one auxiliary
function for each benchmark which performed the loop.
[5] The first time is for the AEGIS shell. The Second is for the
AUX cshell.
The code follows.
T:
(define (fact i) (cond ((eq? i 0) 1)
(T (* i (fact (-1+ i))))))
Common Lisp:
(defun fact (i) (cond ((eq i 0) 1)
(T (* i (fact (1- i))))))
T:
(define (tak x y z)
(cond ((not (fx< y x)) z)
(T
(tak (tak (fx- x 1) y z)
(tak (fx- y 1) z x)
(tak (fx- z 1) x y)))))
Common Lisp:
(defun tak (x y z)
(declare (type integer x)
(type integer y)
(type integer z))
(cond ((not (< y x) z)
(T
(tak (tak (- x 1) y z)
(tak (- y 1) z x)
(tak (- z 1) x y)))))
T:
(define (reverse1 l)
(cond ((null? l) nil)
(T (append (reverse1 (cdr l)) (list (car l))))))
Common Lisp:
(defun reverse1 (l)
(cond ((null l) nil)
(T (append (reverse1 (cdr l )) (list (car l)))))
T:
(define (reverse2 l)
(cond ((null? l) (lambda () l))
(T (lambda () (append (apply (reverse2 (cdr l)) ())
(list (car l)))))))
Common Lisp:
(defun reverse2 (l)
(cond ((null l) (function (lambda () l)))
(T (function
(lamda () (append (apply (reverse2 (cdr l)) ())
(list (car l))))))))
-Charlie Dolan
cpd@UCLA-LOCUS.ARPA
∂08-Oct-84 1301 @USC-ECL.ARPA,@MIT-MC:WHOLEY@CMU-CS-C Benchmark - PERQ CL vs Apollo T
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 8 Oct 84 13:01:43 PDT
Received: from MIT-MC by USC-ECL; Mon 8 Oct 84 12:58:47-PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 8 Oct 84 15:51:34-EDT
Date: Mon, 8 Oct 1984 15:51 EDT
Message-ID: <WHOLEY.12053860153.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Charles Dolan <cpd@UCLA-LOCUS.ARPA>
Cc: Common-Lisp@SU-AI.ARPA, Lisp-Forum@MIT-MC.ARPA, T-Users@YALE.ARPA
Subject: Benchmark - PERQ CL vs Apollo T
In-reply-to: Msg of 8 Oct 1984 13:17-EDT from Charles Dolan <cpd at UCLA-LOCUS.ARPA>
Date: Monday, 8 October 1984 13:17-EDT
From: Charles Dolan <cpd at UCLA-LOCUS.ARPA>
UCLA has a demo unit of the new PERQ 68000 based workstation
running Common Lisp.
The PERQ is not a 68000 based machine. There's a bit-sliced processor inside
of it. It's basically a 16-bit machine.
PERQ DN300 DN460
(tak ...) [3] 6.3 sec 3.4/6.3 sec [2] 1/2.7 sec [2]
Tak runs in under 5 seconds on my Perq. The Perq Common Lisp implementation
has been undergoing extensive tuning during the past few months, and I bet
you've got a somewhat old version.
The current situation is that people at CMU are still doing most of the
development work, while the Lisp people at Perq systems are doing things like
getting better interfaces to the operating system servers up.
Over the past two weeks I've added register instructions to the Lisp
instruction set (full runtime type-checking, by the way). Some benchmarky
things have improved dramatically, for example,
(dotimes (i 1000000)) ; That's one million
took over 20 seconds before the addition of registers, and now takes 5.5
seconds. I bet the register instructions will help some of your other
benchmarks as well.
"Benchmarking is, at best, a black art." I'd like to see some large bechmarks
run on a large number of machines (something like OPS5). I like things along
the lines of compilation speed and how fast the editor reads and writes files.
Those are things that most people do a lot, and spend time waiting for.
Common Lisp and T are very different languages, and I bet I could devise some
benchmarks that ran significantly faster on the Perq than on the Apollo
machines. Have you tried CTAK (TAK using catch and throw)?
I don't want to thwart your benchmarking effort, and I'm not offended or
anything, but I felt I should mention that the Perq Lisp system is still in the
tuning phase.
--Skef
∂10-Oct-84 0156 @USC-ECL.ARPA:GZ@MIT-MC ||
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 10 Oct 84 01:56:07 PDT
Received: from MIT-MC by USC-ECL; Wed 10 Oct 84 01:54:51-PDT
Date: 10 October 1984 04:45-EDT
From: Gail Zacharias <GZ @ MIT-MC>
Subject: ||
To: BUG-LISP @ MIT-MC
(setq x (pnput () T))
||
(eq x (pnput () T))
T
(setq y (implode ()))
||
(eq y (implode ()))
T
(eq x y)
NIL
;That's right, you guessed it:
(pnget x 7)
NIL
(pnget y 7)
(0)
So which is right representation of ||?
∂10-Oct-84 0919 @USC-ECL.ARPA,@MIT-MC:jrg@cmu-cs-spice UCLA Perq
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 10 Oct 84 09:18:49 PDT
Received: from MIT-MC by USC-ECL; Wed 10 Oct 84 09:15:08-PDT
Date: Wednesday, 10 October 1984 11:58:31 EDT
From: Joseph.Ginder@cmu-cs-spice.arpa
To: wholey@cmu-cs-c.arpa
cc: T-Users@yale.arpa, Lisp-Forum@mit-mc.arpa, Common-Lisp@su-ai.arpa
Subject: UCLA Perq
Message-ID: <1984.10.10.15.38.13.Joseph.Ginder@cmu-cs-spice.arpa>
The Perq at UCLA, which I have seen in person, is running the Beta release
of S5 with the "slasher 1" version of lisp -- that is, a pre-release, not
even Beta. Thus, it does not have any of the new interfaces. I believe
that it is using Ucode from before the fast funcall stuff and caching was
put in, but don't recall for sure. That is, the ucode is probably 2 major
revisions old; and at least 1 major revision old. Also, no one has a Perq
lisp yet with the faster startup granted by using only the new interfaces.
(Every version of Perq lisp that I know of still uses the old ones at least
internally -- thus they must be initialized as before -- in addition to the
new, fast initializing versions.)
--Joe
P.S. No Perq has a 68000 in it. Or a 68010. All have board-level,
micro-programmable CPU's that aren't true bit-slices (like AMD2901's) but
have been described as such since the chip used for the ALU is 4-bits wide
and five are used to construct a 20-bit ALU. (No, I don't remember which
chip, but it's not a secret. It's some TI ALU chip.) And though the
current board has a 20-bit wide ALU, external data paths are 16 bits wide.
∂10-Oct-84 1005 @USC-ECL.ARPA:ALAN@MIT-MC ||
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 10 Oct 84 10:04:56 PDT
Received: from MIT-MC by USC-ECL; Wed 10 Oct 84 10:03:55-PDT
Date: 10 October 1984 13:02-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: ||
To: GZ @ MIT-MC
cc: BUG-LISP @ MIT-MC
In-reply-to: Msg of 10 Oct 1984 04:45-EDT from Gail Zacharias <GZ>
Date: 10 October 1984 04:45-EDT
From: Gail Zacharias <GZ>
So which is right representation of ||?
Well I'm pretty sure I have seen code in MacLisp that -knows- that the
printname list of a symbol is always at least one element long, so I would
have to say that (0) is the right answer. This is what READ (another
authority on building symbols) gives you when you type "||", so PNPUT in in
the minority. Since PNPUT is such a low-level kludge (on the LispMachine
it would be spelled "%PNPUT"...) I would have to say that you are simply
violating its contract if you give it a zero-length list.
∂10-Oct-84 1626 @USC-ECL.ARPA:KMP@MIT-MC
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 10 Oct 84 16:26:13 PDT
Received: from MIT-MC by USC-ECL; Wed 10 Oct 84 16:03:26-PDT
Date: 10 October 1984 18:39-EDT
From: Kent M Pitman <KMP @ MIT-MC>
To: ALAN @ MIT-MC, GZ @ MIT-MC
cc: BUG-LISP @ MIT-MC
The problem of || isn't the worst of it. Consider the case of
|/↑@|, |/↑@/↑@|, ...
Also, notice the printer bug that makes
|A/↑@/↑@/↑@/↑@B|
print funny. ie,
(EQ '|A/↑@/↑@/↑@/↑@| 'A) => T
but
(EQ '|A/↑@/↑@/↑@/↑@B| 'AB) => NIL ;thank goodness
These little misfeatures have been known a long time and lots of silly
code exists to handle them (user and system), so I wouldn't advocate
changing them. But I'd file them away to study before playing the
Programming Languages Edition of Trivial Pursuit.
∂10-Oct-84 2038 @USC-ECL.ARPA:ALAN@MIT-MC ↑@
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 10 Oct 84 20:38:11 PDT
Received: from MIT-MC by USC-ECL; Wed 10 Oct 84 20:32:42-PDT
Date: 10 October 1984 23:30-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: ↑@
To: KMP @ MIT-MC
cc: BUG-LISP @ MIT-MC, GZ @ MIT-MC
In-reply-to: Msg of 10 Oct 1984 18:39-EDT from Kent M Pitman <KMP>
Yup. I remember that the screws involving ↑@ were even worse before HIC
arrived on the scene. Basically, ↑@ isn't in the MacLisp character set.
∂05-Dec-84 0859 @USC-ECL.ARPA,@MIT-MC:RLB@SCRC-TENEX GC
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 5 Dec 84 08:59:04 PST
Received: from MIT-MC by USC-ECL; Wed 5 Dec 84 08:57:57-PST
Received: from SCRC-STONY-BROOK by MIT-OZ via Chaosnet; 5 Dec 84 11:49-EST
Received: from SCRC-SUDBURY by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 138109; Wed 5-Dec-84 10:31:21-EST
Date: Wednesday, 5 December 1984, 10:32-EST
From: Richard L. Bryan <RLB at SCRC-TENEX>
Subject: GC
To: ALAN at MIT-MC, DJB at MIT-OZ
cc: bug-lisp at MIT-OZ
In-Reply-To: The message of 4 Dec 84 13:29-EST from Alan Bawden <ALAN at MIT-MC>
Message-ID: <841205103259.7.RLB@SUDBURY.SCRC.Symbolics.COM>
Date: 4 December 1984 13:29-EST
From: Alan Bawden <ALAN @ MIT-MC>
Date: Sat 1 Dec 84 19:28:31-EST
From: Dave Braunegg <DJB at OZ>
When trying to run LISP, I (SETQ BASE 10. IBASE 10.), then did
a fixed-point division. When I then tryed a floating-point division,
I got the error message
GC CALLED FROM ALLOC - LOSE, LISP IS DEAD
This happened several times. What is wrong?
Well, of course this doesn't happen for me as you describe it, but probably
that is because there is something you aren't telling me that you don't
think is important. If you send be a PHOTO of a -complete- session with
MacLisp in which this happens, perhaps we can figure it out.
Doesn't that happen if you have an init file that doesn't
start with (COMMENT ...) ?
∂06-Dec-84 1057 @USC-ECL.ARPA:ALAN@MIT-MC GC
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 6 Dec 84 10:57:27 PST
Received: from MIT-MC by USC-ECL; Thu 6 Dec 84 10:54:30-PST
Date: 6 December 1984 13:47-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: GC
To: KMP @ MIT-MC, RLB @ SCRC-TENEX
cc: BUG-LISP @ MIT-MC, DJB @ MIT-OZ
In-reply-to: Msg of 5 Dec 1984 14:08-EST from Kent M Pitman <KMP>
Date: 5 December 1984 14:08-EST
From: Kent M Pitman <KMP>
Date: Wednesday, 5 December 1984, 10:32-EST
From: Richard L. Bryan <RLB at SCRC-TENEX>
Date: Sat 1 Dec 84 19:28:31-EST
From: Dave Braunegg <DJB at OZ>
I got the error message
GC CALLED FROM ALLOC - LOSE, LISP IS DEAD
Doesn't that happen if you have an init file that doesn't
start with (COMMENT ...) ?
Yes, it does. In fact, I've never seen it for any other reason. After all,
as far as I know, only the startup ALLOC can give that message and
he couldn't be typing expressions before he was out of ALLOC so my guess
is he must have meant this was somewhere in an init file.
I checked his init file. He has none....
When I looked he had a perfectly ordinary init file whose first form was
(COMMENT). However DJB informas me that at the time of the lossage his
init file was offline! I'm sure we can all think of interesting effects
that that might have had...
[ Aside to KMP: I note that the new MacLisp manual doesn't say anything
about init files or what they must/can contain. ]
∂10-Jan-85 1525 @USC-ECL.ARPA:MACRAK@MIT-MC MACRAK's SUBLIS problems
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 10 Jan 85 15:25:12 PST
Received: from MIT-MC by USC-ECL; Thu 10 Jan 85 15:18:43-PST
Date: 10 January 1985 18:12-EST
From: Stavros M. Macrakis <MACRAK @ MIT-MC>
Subject: MACRAK's SUBLIS problems
To: KMP @ MIT-MC, ALAN @ MIT-MC
cc: BUG-LISP @ MIT-MC, JPG @ MIT-MC, WGD @ MIT-MC
In-reply-to: Msg of 9 Jan 1985 22:10-EST from Kent M Pitman <KMP>
Yes, Maclisp Sublis. And yes, I know the implementation of Sublis,
and I know its problems. On the other hand, I didn't feel like fixing them
for myself. As it happens, my application doesn't need the fast lookup
property of Sublis so much as the minimal copying, which puts me in a
Catch-22, because you can't catch out-of-cells traps when the copying
becomes excessive!
Now we all know that Macsyma's out-of-cells trap function does not in fact
screw up property lists, so if Macsyma would suppress ↑A and ↑B interrupts
during the trap, Sublis could be un-Nointerrupt'ed....
In short, Sublis is an incredible crock, I use it because it's handy, it
gives my code an obscure bug, I'm unwilling to fix it, and it's probably not
worth anyone else's time to fix it either unless PDP-10 Maclisp is expected
to last for many years longer.
∂06-Feb-85 1133 @MIT-MC:EB@MIT-OZ the infamous ;NNNNN NOT ASCII VALUE
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Feb 85 11:33:31 PST
Date: Wed, 6 Feb 1985 14:25 EST
Message-ID: <EB.12085574776.BABYL@MIT-OZ>
From: EB%MIT-OZ@MIT-MC.ARPA
To: Bug-Lisp%MIT-OZ@MIT-MC.ARPA
Subject: the infamous ;NNNNN NOT ASCII VALUE
As has been reported many times, typing ↑Z at Tops-20 Maclisp
often causes the above error when Lisp is continued. The following
user-level fix appears to get around the problem:
(sstatus ttyint #↑Z '(lambda n (quit)))
∂22-Feb-85 0235 @MIT-MC:MDC.WAYNE@MIT-OZ Array Bug
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Feb 85 02:35:46 PST
Date: Fri 22 Feb 85 05:41:34-EST
From: Wayne McGuire <MDC.WAYNE%MIT-OZ@MIT-MC.ARPA>
Subject: Array Bug
To: bug-lisp%MIT-OZ@MIT-MC.ARPA
Typing in Lisp
(array image T 1024 1024)
(store (image 314 271) 88)
produces an error code. Why? These lines are from page 75 of the
first edition of Winston's and Horn's ←Lisp←.
-------
∂22-Feb-85 1217 ALAN@MIT-MC Array Bug
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Feb 85 12:16:40 PST
Date: 22 February 1985 15:13-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Array Bug
To: MDC.WAYNE @ MIT-OZ
cc: BUG-LISP @ MIT-MC
In-reply-to: Msg of Fri 22 Feb 85 05:41:34-EST from Wayne McGuire <MDC.WAYNE%MIT-OZ at MIT-MC.ARPA>
Date: Fri 22 Feb 85 05:41:34-EST
From: Wayne McGuire <MDC.WAYNE at OZ>
To: bug-lisp at OZ
Re: Array Bug
Typing in Lisp
(array image T 1024 1024)
(store (image 314 271) 88)
produces an error code. Why?
Are the numbers in this bug report decimal or octal?
If they are decimal (as I suspect they must be because of the "88") then
the answer is: Because an array with 1024↑2 elements is bigger than can
fit in the address space of a PDP10. Of course MacLisp should signal an
error at the time you ask for an array so impossibly big, rather than
trashing your lisp world, perhaps that might get fixed.
If they are in octal then the answer is that there is a bug (that I just
fixed in the source) in the routine that STORE uses to determine the size
of an array.
These lines are from page 75 of the
first edition of Winston's and Horn's ←Lisp←.
Really? I guess they never tried it in MacLisp.
∂20-Mar-85 1532 @MIT-MC:Margolin.Multics@MIT-MULTICS.ARPA defsubst in Maclisp
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 15:32:22 PST
Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 20 MAR 85 18:30:58 EST
Date: Wed, 20 Mar 85 18:30 EST
From: Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Subject: defsubst in Maclisp
To: lisp-forum@MIT-MC.ARPA
Message-ID: <850320233024.242229@MIT-MULTICS.ARPA>
Has anyone written a DEFSUBST for Maclisp (or a similar dialect)? (See
the Chineual for a description of DEFSUBST.) I have been trying to
write one for several days, mostly just as an academic exercise. I
managed to implement a pretty simple one, which doesn't handle &keywords
(&optional, &rest, etc) pretty quickly (it expands into an equivalent
DEFUN at (load eval) time, and a DEFMACRO at compile-time). I was in
the process of modifying it to deal with &keywords when I realized that
it should then also do destructuring, in order to be completely
compatible with DEFUN. At this point I gave up.
I don't really need this, but I am curious whether anyone has done it,
and what the compile-time code looks like.
barmar
∂20-Mar-85 2038 @MIT-MC:KMP@SCRC-STONY-BROOK defsubst in Maclisp
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 20:38:39 PST
Received: from SCRC-STONY-BROOK by MIT-MC via Chaosnet; 20 MAR 85 22:29:41 EST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 200859; Wed 20-Mar-85 20:01:10-EST
Date: Wed, 20 Mar 85 20:01 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: defsubst in Maclisp
To: Margolin@MIT-MULTICS.ARPA, lisp-forum@MIT-MC.ARPA
In-Reply-To: <850320233024.242229@MIT-MULTICS.ARPA>
Message-ID: <850320200132.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wed, 20 Mar 85 18:30 EST
From: Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Re: defsubst in Maclisp
Has anyone written a DEFSUBST for Maclisp (or a similar dialect)?
Yes. I think the code is in LIBLSP;LISPM on MC with my other LispM
compatibility stuff (WITH-OPEN-FILE, WITH-OPEN-STREAM, ONCE-ONLY,
MEXP, ...).
∂24-Mar-85 1315 ALAN@MIT-MC mapcan and get
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 24 Mar 85 13:15:19 PST
Date: 24 March 1985 16:14-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: mapcan and get
To: RJH @ MIT-OZ
cc: BUG-LISP @ MIT-MC
In-reply-to: Msg of Sat 23 Mar 85 17:19:48-EST from Bob Hall <RJH%MIT-OZ at MIT-MC.ARPA>
Your bug report doesn't say what you think the problem is. The expected
behavior, given that MAPCAN calls NCONC to put together it's answer, is that
after the first time you call MAPCAN-TEST you have clobbered the A and B
properties of RIGHT. The second time you call MAPCAN-TEST the answer is
thus a circular list that prints: "(D E E F E F E F E F E F E F ...)". If
you observe some -other- behavior, you should send a more complete bug
report. If you find -this- behavior confusing, you need to understand side
effects in Lisp better.
∂05-May-85 1648 @MIT-MC:KMP@SCRC-STONY-BROOK.ARPA MDC.WAYNE: "list" command
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 16:48:18 PDT
Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 5 MAY 85 19:47:36 EDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 230447; Sun 5-May-85 19:45:19-EDT
Date: Sun, 5 May 85 19:44 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: MDC.WAYNE: "list" command
To: Bug-LISP@MIT-MC.ARPA
Message-ID: <850505194427.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I sent MDC.WAYNE some mail suggesting he find out about MAPATOMS,
BOUNDP, FBOUNDP, MAKNUM, MUNKAM, and such ...
∂07-May-85 1353 @MIT-MC:PWEYHRAUCH@SUMEX-AIM.ARPA EXEC/MACLISP interface problem
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 May 85 13:53:22 PDT
Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA; 7 MAY 85 16:50:16 EDT
Date: Tue 7 May 85 13:49:34-PDT
From: Daniel S. Blom
Subject: EXEC/MACLISP interface problem
Sender: PWEYHRAUCH@SUMEX-AIM.ARPA
To: bug-lisp@MIT-MC.ARPA
cc: zzz.d@SU-SCORE.ARPA
Reply-To: PWEYHRAUCH@SUMEX-AIM.ARPA
I am having this problem with the FOL program. What happens
is an all zero page is created by MACLISP but not saved by
the EXEC SAVE (or CSAVE) command. After the saved program
is loaded into core with GET, the non-zero page isn't in the
map. After actually starting the program with the START
command, when MACLISP tries to write on that page, it prints
(if enabled--FOL usually traps errors itself using ERRSET) a
memory protection violation message and signals an ERRSET
trappable error. The systems person I talked to here (MRC)
suggested I complain to this mailbox. What do you suggest?
Thanks
Dan Blom
-------
∂07-May-85 1404 @MIT-MC:PWEYHRAUCH@SUMEX-AIM.ARPA EXEC/MACLISP interface problem
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 May 85 14:04:15 PDT
Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA; 7 MAY 85 17:02:37 EDT
Date: Tue 7 May 85 14:01:35-PDT
From: Daniel S. Blom
Subject: EXEC/MACLISP interface problem
Sender: PWEYHRAUCH@SUMEX-AIM.ARPA
To: BUG-LISP@MIT-MC.ARPA
cc: ZZZ.D@SU-SCORE.ARPA
Reply-To: PWEYHRAUCH@SUMEX-AIM.ARPA
I am having this problem with the FOL program. What happens
is an all zero page is created by MACLISP but not saved by
the EXEC SAVE (or CSAVE) command. After the saved program
is loaded into core with GET, the non-zero page isn't in the
map. After actually starting the program with the START
command, when MACLISP tries to write on that page, it prints
(if enabled--FOL usually traps errors itself using ERRSET) a
memory protection violation message and signals an ERRSET
trappable error. The systems person I talked to here (MRC)
suggested I complain to this mailbox. What do you suggest?
Thanks
Dan Blom
-------
∂07-May-85 1411 @MIT-MC:KMP@SCRC-STONY-BROOK.ARPA EXEC/MACLISP interface problem
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 May 85 14:10:41 PDT
Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 7 MAY 85 17:03:34 EDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232146; Tue 7-May-85 16:54:36-EDT
Date: Tue, 7 May 85 16:55 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: EXEC/MACLISP interface problem
To: PWEYHRAUCH@SUMEX-AIM.ARPA, bug-lisp@MIT-MC.ARPA
cc: zzz.d@SU-SCORE.ARPA
In-Reply-To: The message of 7 May 85 16:49-EDT from Daniel S. Blom
Message-ID: <850507165556.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue 7 May 85 13:49:34-PDT
From: Daniel S. Blom
Subject: EXEC/MACLISP interface problem
Sender: PWEYHRAUCH@SUMEX-AIM.ARPA
To: bug-lisp@MIT-MC.ARPA
cc: zzz.d@SU-SCORE.ARPA
Reply-To: PWEYHRAUCH@SUMEX-AIM.ARPA
I am having this problem with the FOL program. What happens
is an all zero page is created by MACLISP but not saved by
the EXEC SAVE (or CSAVE) command. After the saved program
is loaded into core with GET, the non-zero page isn't in the
map. After actually starting the program with the START
command, when MACLISP tries to write on that page, it prints
(if enabled--FOL usually traps errors itself using ERRSET) a
memory protection violation message and signals an ERRSET
trappable error. The systems person I talked to here (MRC)
suggested I complain to this mailbox. What do you suggest?
Thanks
Dan Blom
-------
What is the FOL program? I think we need more context.
∂07-May-85 1440 @MIT-MC:KMP@SCRC-STONY-BROOK.ARPA [Daniel S. Blom: Re: EXEC/MACLISP interface problem]
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 May 85 14:31:13 PDT
Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 7 MAY 85 17:30:36 EDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232179; Tue 7-May-85 17:25:55-EDT
Date: Tue, 7 May 85 17:27 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: [Daniel S. Blom: Re: EXEC/MACLISP interface problem]
To: BUG-LISP@MIT-MC.ARPA
Message-ID: <850507172716.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Return-path: <PWEYHRAUCH@SUMEX-AIM.ARPA>
Received: from SUMEX-AIM.ARPA by SCRC-STONY-BROOK.ARPA via INTERNET with SMTP id 232170; 7 May 85 17:17:22-EDT
Date: Tue 7 May 85 14:21:06-PDT
From: Daniel S. Blom
Subject: Re: EXEC/MACLISP interface problem
Sender: PWEYHRAUCH@SUMEX-AIM.ARPA
To: KMP@SCRC-STONY-BROOK.ARPA
cc: zzz.d@SU-SCORE.ARPA
Reply-To: PWEYHRAUCH@SUMEX-AIM.ARPA
In-Reply-To: Message from "Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>" of Tue 7 May 85 14:03:44-PDT
So you did get my message. I got something from Mailer@SRI-AI that
said my message "failed." So I sent it again. Sorry if you got two
copies.
FOL is a proof checker written entirely in a LISP-like language that
sits on top of MACLISP (right now), implemented by macros. It's running
interpreted entirely now. I don't know how the all zero page is created,
but it's there just after loading all the FOL files.
-------
∂07-May-85 1451 GJC@MIT-MC EXEC/MACLISP interface problem
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 May 85 14:51:36 PDT
Date: Tue, 7 May 85 17:42:46 EST
From: George J. Carrette <GJC@MIT-MC>
Subject: EXEC/MACLISP interface problem
To: KMP@SCRC-STONY-BROOK
cc: BUG-LISP@MIT-MC, PWEYHRAUCH@SUMEX-AIM, zzz.d@SU-SCORE
In-reply-to: Msg of Tue 7 May 85 16:55 EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Message-ID: <[MIT-MC].490476.850507.GJC>
You dont really need any more context, this ZERO page problem
is a known maclisp problem when using the EXEC SAVE command.
As I recall GSB or ALAN had a work-around or perhaps a fix.
You might also tell people about the SHARESAVE command (or whatever it
is called) from Yale. Its useful enought that it should be included
with tops-20 maclisp distributions.
∂07-May-85 1503 @MIT-MC:KMP@SCRC-STONY-BROOK.ARPA EXEC/MACLISP interface problem
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 May 85 15:03:10 PDT
Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA; 7 MAY 85 18:00:39 EDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232214; Tue 7-May-85 17:54:47-EDT
Date: Tue, 7 May 85 17:56 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: EXEC/MACLISP interface problem
To: GJC@MIT-MC.ARPA
cc: KMP@SCRC-STONY-BROOK.ARPA, BUG-LISP@MIT-MC.ARPA,
PWEYHRAUCH@SUMEX-AIM.ARPA, zzz.d@SU-SCORE.ARPA
In-Reply-To: <[MIT-MC].490476.850507.GJC>
Message-ID: <850507175608.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 7 May 85 17:42:46 EST
From: George J. Carrette <GJC@MIT-MC>
You dont really need any more context, this ZERO page problem
is a known maclisp problem when using the EXEC SAVE command.
As I recall GSB or ALAN had a work-around or perhaps a fix.
You might also tell people about the SHARESAVE command (or whatever it
is called) from Yale. Its useful enought that it should be included
with tops-20 maclisp distributions.
The program is SHARE.EXE. On MIT machines, it's available in the default
search rules and HELP SHARE tells how to use it. I seem to remember that
it does go out in distributions (or that we'd at least been thinking
about sending it out for years) so it might already be there, but if it's
not we could put it someplace where it can be FTP'd.
∂10-May-85 1752 host MIT-MC.ARPA EXEC/MACLISP interface problem
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 May 85 17:51:51 PDT
Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA; 10 May 85 19:57:07 EST
Date: Fri 10 May 85 16:55:34-PDT
From: Peter Weyhrauch <PWEYHRAUCH@SUMEX-AIM.ARPA>
Subject: EXEC/MACLISP interface problem
To: alan@MIT-MC.ARPA
cc: bug-lisp@MIT-MC.ARPA, gjc@MIT-MC.ARPA, zzz.d@SU-SCORE.ARPA,
kmp@SCRC-STONY-BROOK.ARPA
Thanks to the original author of the MIDAS program also,
whoever that may be.
Dan Blom
-------
∂19-May-85 0117 @MIT-MC:MKL@SRI-CSL distribution copies
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 May 85 01:17:43 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 19 MAY 85 04:16:05 EDT
Received: from MIT-MC by MIT-OZ via Chaosnet; 19 May 85 04:14-EDT
Received: from SRI-CSL.ARPA by MIT-MC.ARPA; 19 May 85 04:15:04 EST
Date: 19 May 1985 0110-PDT
From: Mark K. Lottor <MKL@SRI-CSL.ARPA>
Subject: distribution copies
To: bug-maclisp%oz@MIT-MC.ARPA
Where can the standard maclisp distribution stuff be found?
Also, our current version of Maclisp doesn't delete characters
on the screen using backspace (i.e. it echoes deleted characters).
Is this something that only works right if you have a VTS% jsys
or do we just have Maclisp terminal types compiled in wrong?
Mark
-------
∂19-May-85 0236 @MIT-MC:GUMBY@MIT-MC distribution copies
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 May 85 02:34:43 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 19 MAY 85 05:36:15 EDT
Received: from MIT-MC by MIT-OZ via Chaosnet; 19 May 85 05:34-EDT
Date: Sun, 19 May 85 05:34:21 EST
From: David Vinayak Wallace <GUMBY@MIT-MC>
Subject: distribution copies
To: MKL@SRI-CSL
cc: bug-maclisp@MIT-OZ
In-reply-to: Msg of 19 May 1985 0110-PDT from Mark K. Lottor <MKL at SRI-CSL.ARPA>
Message-ID: <[MIT-MC].510163.850519.GUMBY>
Date: 19 May 1985 0110-PDT
From: Mark K. Lottor <MKL at SRI-CSL>
Also, our current version of Maclisp doesn't delete characters
on the screen using backspace (i.e. it echoes deleted characters).
Is this something that only works right if you have a VTS% jsys
or do we just have Maclisp terminal types compiled in wrong?
You need to have vts. If you really feel up to hacking ttytypes, fix the
code for CURSORPOS and RUBOUT in *LISP (but don't eat a big lunch
beforehand!).
Now that twenex TECO has a seperate TECTRM file, perhaps MACLISP could be
tought to use the same thing? It would cost a couple of pages, I think.
david
∂19-May-85 1240 @MIT-MC:FREEMAN@SUMEX-AIM Re: distribution copies
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 May 85 12:40:20 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 19 MAY 85 15:39:28 EDT
Received: from MIT-MC by MIT-OZ via Chaosnet; 19 May 85 15:37-EDT
Received: from SUMEX-AIM.ARPA by MIT-MC.ARPA; 19 May 85 15:38:42 EST
Date: Sun 19 May 85 12:36:21-PDT
From: Andy Freeman <FREEMAN@SUMEX-AIM.ARPA>
Subject: Re: distribution copies
To: GUMBY@MIT-MC.ARPA
cc: MKL@SRI-CSL.ARPA, bug-maclisp%MIT-OZ@MIT-XX.ARPA
In-Reply-To: Message from "David Vinayak Wallace <GUMBY@MIT-MC>" of Sun 19 May 85 02:36:28-PDT
(sstatus linmode t) is another alternative. It is easier to
"implement", but the results aren't as good as real terminal support.
(Tops-20 users expect ↑W (↑U) to delete the previous word (current
line) and usually can delete across lines; real tenex users expect
neither.) All you really get is backspace and you have to type <cr>
to get maclisp to respond.
-andy
-------
∂06-Jun-85 2159 @MIT-MC.ARPA:sjk@SRI-AI.ARPA Re: distribution copies
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Jun 85 21:58:50 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 7 JUN 85 00:59:04 EDT
Received: from MIT-XX by MIT-OZ via Chaosnet; 7 Jun 85 00:58-EDT
Received: from SRI-AI.ARPA by MIT-XX.ARPA with TCP; Fri 7 Jun 85 00:58:22-EDT
Date: Thu 6 Jun 85 21:57:11-PDT
From: Scott J. Kramer <sjk@SRI-AI.ARPA>
Subject: Re: distribution copies
To: FREEMAN@SUMEX-AIM.ARPA, GUMBY@MIT-MC.ARPA
cc: MKL@SRI-CSL.ARPA, bug-maclisp%MIT-OZ@MIT-XX.ARPA
In-Reply-To: Message from "Andy Freeman <FREEMAN@SUMEX-AIM.ARPA>" of Sun 19 May 85 12:41:34-PDT
Reply-To: sjk@sri-spam
I have some code somewhere that implements VTS-like rubout processing
and CURSORPOS in Maclisp with SFA's. I had it semi-working here, but
was spending most of my time on UNIX and never fully debugged it. If
there's sufficient interest, I'll leave the files somewhere on OZ after
I dig them out of my archives. I originally got the code from John
Ellis at Yale.
You could probably use TEXTI (or...? I'm out of touch with alot of
Twenex stuff lately) to implement fancy input processing if you like
MIDAS. The Yale stuff seemed to work sufficiently, tho'.
scott
-------
∂11-Jun-85 0553 MACRAK@MIT-MC.ARPA Timit
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 05:53:24 PDT
Date: Tue, 11 Jun 85 08:53:56 EDT
From: Stavros M. Macrakis <MACRAK@MIT-MC.ARPA>
Subject: Timit
To: BUG-LISP@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].538214.850611.MACRAK>
Does anyone know where to find Jonl's old Timit fnc?
(timit (foobar)) => 4.566
Just times one call of foobar.
Simpler than the nice package on Liblsp, but still handy.
∂11-Jun-85 0927 @MIT-MC.ARPA:KMP@SCRC-STONY-BROOK.ARPA Timit
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 09:26:37 PDT
Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 11 Jun 85 12:11:26 EST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 251982; Tue 11-Jun-85 12:07:32-EDT
Date: Tue, 11 Jun 85 12:09 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Timit
To: MACRAK@MIT-MC.ARPA
cc: BUG-LISP@MIT-MC.ARPA
In-Reply-To: <[MIT-MC.ARPA].538214.850611.MACRAK>
Message-ID: <850611120933.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 11 Jun 85 08:53:56 EDT
From: Stavros M. Macrakis <MACRAK@MIT-MC.ARPA>
Does anyone know where to find Jonl's old Timit fnc?
(timit (foobar)) => 4.566
Just times one call of foobar.
Simpler than the nice package on Liblsp, but still handy.
LIBLSP;BS (see LIBDOC;BS for `documentation').
∂24-Jun-85 1754 @MIT-MC.ARPA:Hornig@SCRC-STONY-BROOK.ARPA Common Lisp defsetf
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 24 Jun 85 17:54:14 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 24 JUN 85 20:49:27 EDT
Received: from MIT-MC by MIT-OZ via Chaosnet; 24 Jun 85 20:50-EDT
Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 24 Jun 85 20:20:26 EST
Received: from BIG.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 262063; Mon 24-Jun-85 20:18:14-EDT
Date: Mon, 24 Jun 85 20:19 EDT
From: Charles Hornig <Hornig@SCRC-STONY-BROOK.ARPA>
Subject: Common Lisp defsetf
To: Richard E. Zippel <RZ@ZERMATT.SCRC.Symbolics.COM>,
BUG-LISP%OZ@MIT-MC.ARPA
In-Reply-To: <850604214119.7.RZ@ZERMATT>
Message-ID: <850624201934.6.HORNIG@BIG.SCRC.Symbolics.COM>
Date: Tue, 4 Jun 85 21:41 EDT
From: Richard E. Zippel <RZ@ZERMATT>
In Symbolics 3670 Release 6.0, IP-TCP 29.0, MLSite 7.2, Mailer 43.0,
Experimental Imagen Spooler 2.1, Experimental Schema 84.0,
microcode TMC5-IO4-MIC 319, on Zermatt:
I occasionally define a simple setf method i.e.:
(cl:defsetf nth-string set-nth-string)
and then define that a more complex definition is required, i.e.:
(cl:defsetf nth-string (string i) (char)
`(set-nth-string ,char ,string ,i))
It seems that the lt::trivial-setf-method property is not deleted when
the more complex property is added and thus the most recent defsetf does
not take effect.
Thank you for reporting this problem. It will be fixed in a future
release.
∂16-Sep-85 1547 @MIT-MC.ARPA:J.Dalton%edxa@UCL-CS.ARPA Scheme availability
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 16 Sep 85 15:45:16 PDT
Received: from BRL-AOS.ARPA by MIT-MC.ARPA 16 Sep 85 18:44:23 EDT
Received: from ucl-cs.arpa by AOS.BRL.ARPA id a001447; 16 Sep 85 18:37 EDT
Received: from edxa.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a003533;
13 Sep 85 17:36 BST
From: DALTON FHL (on ERCC DEC-10) <J.Dalton%edxa@UCL-CS.ARPA>
Date: Friday, 13-Sep-85 17:29:56-GMT
Message-ID: <132361-565-240@EDXA>
To: lisp-forum <lisp-forum%mit-mc.arpa%cs.ucl.ac.uk@UCL-CS.ARPA>
Subject: Scheme availability
--------
I realize this is not the ideal forum for this request, but it seemed a
possible place to begin.
I am looking for a Scheme system that works on a VAX or Sun running
4.2 BSD. I recall from the last Lisp conference that people at
Indiana were willing to distribute their system, but I don't know
their network address. Also, where can I get the Revised Revised
Report?
Thanks for any help.
J. Dalton, AIAI, U. of Edinburgh
--------
∂06-Nov-85 1418 @MIT-MC.ARPA:Soley@MIT-MC.ARPA Common Lisp meeting
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Nov 85 14:18:06 PST
Received: from MIT-CHERRY.ARPA by MIT-MC.ARPA via Chaosnet; 6 NOV 85 16:56:25 EST
Date: Wed, 6 Nov 85 16:56 EST
From: Soley@MIT-MC.ARPA
Subject: Common Lisp meeting
To: RZ@MIT-ZERMATT.ARPA
cc: Soley@MIT-MC.ARPA, INFO-LISPM-MIT@MIT-REAGAN.ARPA,
INFO-NIL@MIT-MC.ARPA, INFO-MACLISP-LOCALS@MIT-MC.ARPA
In-Reply-To: The message of 6 Nov 85 10:27-EST from Richard E. Zippel <RZ at ZERMATT>
Message-ID: <851106165614.1.SOLEY@CHERRY.MIT.EDU>
Date: Wed, 6 Nov 85 10:27 EST
From: Richard E. Zippel <RZ at MIT-ZERMATT.ARPA>
To: Soley at MIT-MC.ARPA
Re: Common Lisp meeting
Date: Tue, 5 Nov 85 17:04 EST
From: Soley@MIT-MC.ARPA
Date: Tue, 5 Nov 85 10:59 EST
From: Richard E. Zippel <RZ@MIT-ZERMATT.ARPA>
Is there any organization among the MIT people as to who will represent
MIT at the meeting?
Do you want to send a message out to BUG-LISPM, INFO-LISPM asking for
volunteers?
RZ has pointed out that there should probably be some organization among
the MIT people attending the next Common Lisp meeting, especially since
there will probably be a limit to the number of VOTING attendees from
each organization. Anyone want to volunteer, or have any other good
organizational ideas?
-- Richard
∂16-Jan-86 1847 @MC.LCS.MIT.EDU:carr%utah-orion@utah-cs.arpa (TRACE q1 q2 ... ) patterns
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 16 Jan 86 18:47:16 PST
Received: from utah-cs.ARPA by MC.LCS.MIT.EDU 16 Jan 86 21:26:00 EST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
id AA07519; Thu, 16 Jan 86 17:05:25 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
id AA20321; Thu, 16 Jan 86 17:05:17 MST
Message-Id: <8601170005.AA20321@utah-orion.ARPA>
Date: 16 Jan 86 16:47 MST
From: Harold Carr <carr%utah-orion@utah-cs.arpa>
To: lisp-forum@mit-mc.arpa
Cc: carr%utah-orion@utah-cs.arpa, pass%utah-orion@utah-cs.arpa
Subject: (TRACE q1 q2 ... ) patterns
I have written a generalized trace utility and need some examples to
try it out on. If you have some favorite patterns of TRACE usage, i.e:
(trace (foo cond (pred x)))
I would appreciate it if you would mail them to me. Actually, since
this is a generalized trace - I could use any of your typical patterns
of usage of debugging tools.
Please mail to CARR@UTAH-20
Thanks for you help, Harold
∂05-Feb-86 1456 JAR@MC.LCS.MIT.EDU ALLFILES behavior
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 Feb 86 14:56:36 PST
Date: Wed, 5 Feb 86 17:57:47 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: ALLFILES behavior
To: BUG-LISP@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].808858.860205.JAR>
In Maclisp 2138 on ITS:
Small bug in the Pitmanual (page 215): PROBEF understands >, while
ALLFILES doesn't.
∂10-Apr-86 1704 @MC.LCS.MIT.EDU:KMP@SCRC-STONY-BROOK.ARPA Use of LISP-FORUM
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Apr 86 17:04:03 PST
Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 10 Apr 86 20:04:29 EST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 460847; Thu 10-Apr-86 19:19:37-EST
Date: Thu, 10 Apr 86 19:20 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Reply-To: LISP-FORUM-REQUEST@MIT-MC.ARPA
Subject: Use of LISP-FORUM
To: LISP-FORUM@MIT-MC.ARPA
cc: Ortiz-Luis@YALE.ARPA
In-Reply-To: <8604101934.AA18790@yale-cheops.YALE.ARPA>
Message-ID: <860410192027.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Please disregard the previous message to LISP-FORUM from ortiz-luis@YALE.
Their mailer database had incorrect information that led them to believe
that the list was operated out of Yale. In fact, the list is maintained
at MIT-MC.
For the most part, the Common Lisp discussion lists have taken over most
of LISP-FORUM's original functions. This list continues to be maintained
to reach a wider distribution for the now-relatively-rare situation where
a query must reach a broad audience or where a topic of very general
interest comes up for which there is no other appropriate list.
LISP-FORUM is not a bulletin board or a day-to-day discussion list. It
reaches a very large number of very busy people and should not be used
casually. Potential contributors are encouraged to carefully consider
anything before sending it to the list.
Requests for further information about or changes to the LISP-FORUM list
should be addressed to LISP-FORUM-REQUEST@MIT-MC.ARPA .
∂21-Apr-86 1758 CSTACY@MC.LCS.MIT.EDU ITS names
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Apr 86 17:58:29 PST
Date: Mon, 21 Apr 86 20:59:31 EST
From: "Christopher C. Stacy" <CSTACY@MC.LCS.MIT.EDU>
Subject: ITS names
To: BUG-LISP@MC.LCS.MIT.EDU
cc: BUG-DDT@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].891348.860421.CSTACY>
(STATUS HSNAME 'PINTO 'MX) gives an ILOPR on MC, a DDT BUG on AI or MX.
∂07-May-86 1852 @MC.LCS.MIT.EDU:JAR@MC.LCS.MIT.EDU ubiquitous prettyprinter bug
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 May 86 18:52:08 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 MAY 86 21:52:46 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 1141; Wed 7-May-86 21:50:54-EDT
Date: Wed, 7 May 86 21:50 EDT
From: Jonathan A Rees <JAR@MIT-MC.ARPA>
Subject: ubiquitous prettyprinter bug
To: bug-lisp@MIT-MC.ARPA, bug-lispm@MIT-MC.ARPA
cc: t-bugs@YALE.ARPA
Message-ID: <860507215037.2.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>
[User input is in lower case, system output is in upper case]
(defun foo (@x) `(a , @x b))
FOO
(foo 'z)
(A Z B)
(grindef foo)
(DEFUN FOO (@X)
`(A ,@X B))
The pretty printer generates incorrect output for backquote forms
containing ,<var> where <var> is a variable whose name begins with the
character @. A bug easily sympathized with, but a bug nonetheless.
- Jonathan
∂20-May-86 1141 ZVONA@AI.AI.MIT.EDU
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 20 May 86 11:41:32 PDT
Date: Tue, 20 May 86 14:39:48 EDT
From: David Chapman <ZVONA@AI.AI.MIT.EDU>
To: buglisphack@SU-AI.ARPA
Message-ID: <[AI.AI.MIT.EDU].43081.860520.ZVONA>
Hi, I'm gc'ing mailing lists on MC. SAILBUGLISPHACK@MC forwards to
BUGLISPHACK@SU-AI. Is this mailing list still current and accessed
through MC?
Thanks.
∂28-Oct-86 1431 @MC.LCS.MIT.EDU:long@YALE.ARPA Testing mailing list lisp-forum from yale.arpa
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 86 14:31:42 PST
Received: from yale-eli.YALE.ARPA by MC.LCS.MIT.EDU 28 Oct 86 16:37:47 EST
Received: by yale-eli.YALE.ARPA; Tue, 28 Oct 86 16:38:18 est
Date: Tue, 28 Oct 86 16:38:18 est
From: "H. Morrow Long" <long@YALE.ARPA>
Message-Id: <8610282138.AA00761@yale-eli.YALE.ARPA>
To: lisp-forum@YALE.ARPA
Subject: Testing mailing list lisp-forum from yale.arpa
This is a mailing list test. Please ignore.
The Facility
∂21-Dec-86 1915 @AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:RDZ@AI.AI.MIT.EDU Gee, that's not my host's name
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 Dec 86 19:15:50 PST
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 Dec 86 22:15:54 EST
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 DEC 86 20:28:45 EST
Received: from REAGAN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 20 Dec 86 13:25-EST
Received: from NULLSTELLENSATZ.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 16312; Sat 20-Dec-86 13:22:41 EST
Date: Sat, 20 Dec 86 13:22 EST
From: Ramin Zabih <RDZ@AI.AI.MIT.EDU>
Subject: Gee, that's not my host's name
To: bug-lisp@OZ.AI.MIT.EDU, bug-its@AI.AI.MIT.EDU
Message-ID: <861220132243.9.RDZ@NULLSTELLENSATZ.AI.MIT.EDU>
Typing :FINGER on AI just produced this output:
-User- --Full name-- Jobnam Idle TTY -Console location-
___005 < [not logged in] HACTRN 23.T05 906 x1729 CENT, OAF
KWH Ken Haase HACTRN *:**.T15 Net site PREP (Chaos)
DPH Daniel Huttenlocher HACTRN 46.T16 723 x8843 Alan, DPH
RDZ Ramin Zabih F T23 <<error printing host>>: 709 x8827 RDZ, Zvona (Chaos)
It seems that someone is confused about the name of the 3600 I'm using...
∂21-Dec-86 1935 ALAN@AI.AI.MIT.EDU Gee, that's not his host's name
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 Dec 86 19:35:04 PST
Date: Sun, 21 Dec 86 22:34:01 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Gee, that's not his host's name
To: RDZ@AI.AI.MIT.EDU
cc: BUG-ITS@AI.AI.MIT.EDU, BUG-LISP@AI.AI.MIT.EDU
In-reply-to: Msg of Sat 20 Dec 86 13:22 EST from Ramin Zabih <RDZ at AI.AI.MIT.EDU>
Message-ID: <133383.861221.ALAN@AI.AI.MIT.EDU>
Date: Sat, 20 Dec 86 13:22 EST
From: Ramin Zabih <RDZ at AI>
Typing :FINGER on AI just produced this output:
...
RDZ Ramin Zabih F T23 <<error printing host>>: 709 x8827 RDZ, Zvona (Chaos)
It seems that someone is confused about the name of the 3600 I'm using...
RDZ's host has a short name of "NULL". He's been expecting the name "NULL"
to break some program ever since he named it that. I presume thats why he
mailed this bug report to Bug-LISP.
Nothing's broken actually. I was just hacking him...
∂05-May-87 2113 @AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:jrd@MEDIA-LAB.MEDIA.MIT.EDU CL file-position ignores byte size
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 May 87 21:13:17 PDT
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 6 May 87 00:13:04 EDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 MAY 87 00:12:05 EDT
Received: from EDDIE.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 6 May 87 00:11-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <AA03657@EDDIE.MIT.EDU>; Wed, 6 May 87 00:09:36 EDT
Received: by media-lab.MIT.EDU (5.54/4.8) id AA08364; Wed, 6 May 87 00:09:19 EDT
Date: Wed, 6 May 87 00:09:19 EDT
From: Jim Davis <jrd@MEDIA-LAB.MEDIA.MIT.EDU>
Message-Id: <8705060409.AA08364@media-lab.MIT.EDU>
To: bug-lisp@oz
Subject: CL file-position ignores byte size
In Symbolics 3650 Release 6.G, IP-TCP 29.13,
Experimental Local Fixes 1.0, Versatec 9.0, Spire 17.2,
Experimental DECTALK 1.1, Experimental DICTIONARY 2.0, BROWN 1.0,
Experimental SPELL 2.0, Experimental Prose 2000 Speech Synthesizer 3.0,
Experimental Segmentation Editor 1.11, DP200 Speech Recognizer 1.0,
Experimental Streets 1.0, Experimental Route Finder 1.1,
Experimental Location 1.0, Experimental Route Describer 1.0,
Experimental Direction Assistance Toplevel 1.4,
Experimental Direction Assistance 1.0, Experimental ASSP 2.0,
microcode NBS-COL-MIC 388, on Obvious:
In Rel 6.G, the CL file-position function always returns a value
calculated using 8bit bytes. Thus:
(setq s (open "EMS:/u2/jrd/experiment/1l1.pt"
:direction :input
:element-type '(unsigned-byte 16)))
(dotimes (i 10) (read-byte s))
(file-position s)
==> 20
Perhaps you have fixed this in 7.1
∂09-May-87 0455 @MC.LCS.MIT.EDU:TMB%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Smalltalk-80 Classes for Symbolics and/or CommonLisp
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 May 87 04:55:35 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 MAY 87 07:53:42 EDT
Date: Sat 9 May 87 07:49:55-EDT
From: "Thomas M. Breuel" <TMB%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Smalltalk-80 Classes for Symbolics and/or CommonLisp
To: pcl-hackers%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
common-lisp%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
info-lispm%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
lisp-forum%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
cc: tmb%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Message-ID: <12300974291.86.TMB@OZ.AI.MIT.EDU>
I am looking for an implementation of the Smalltalk-80 classes, or a
subset of them, on the Symbolics 3600 and/or under Common Lisp. I am
only interested in this for new program developments, not porting, so
compatibility is not a strict requirement. Implementations using
flavours or PCL are fine. If you have such a beast, or a pointer to
one, please let me know.
Thomas.
tmb@prep.ai.mit.edu
-------
∂01-Oct-87 2023 ZVONA@AI.AI.MIT.EDU
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 20:23:18 PDT
Date: Thu, 1 Oct 87 23:30:53 EDT
From: David Chapman <ZVONA@AI.AI.MIT.EDU>
To: BUG-LISP@AI.AI.MIT.EDU
Message-ID: <263565.871001.ZVONA@AI.AI.MIT.EDU>
When I CFTP to REAGAN and get a directory listing, it comes out in
a completely random order, which is difficult to work with. It should
be sorted alphabetically like other ftp directory listings are.
(This is cftping from an ITS; I can't tell you what version of Genera
REAGAN is running, because I'm in California.)
∂01-Oct-87 2031 ZVONA@AI.AI.MIT.EDU
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 20:31:43 PDT
Date: Thu, 1 Oct 87 23:39:03 EDT
From: David Chapman <ZVONA@AI.AI.MIT.EDU>
To: BUG-LISP@AI.AI.MIT.EDU
Message-ID: <263567.871001.ZVONA@AI.AI.MIT.EDU>
Oops, that was supposed to go to bug-lispm. Orry. Can someone forward it
there? Thanks..
∂05-Oct-87 0934 @AI.AI.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 87 09:34:12 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 5 Oct 87 12:41:26 EDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 248667; Mon 5-Oct-87 12:32:18 EDT
Date: Mon, 5 Oct 87 12:32 EDT
From: KMP@STONY-BROOK.SCRC.Symbolics.COM
To: BUG-LISP@AI.AI.MIT.EDU
References: <263565.871001.ZVONA@AI.AI.MIT.EDU>
Message-ID: <871005123222.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
[The referenced message has been redirected:
Correcting "Bug-Lisp" -> "Bug-LispM"
BUG-LISP@AI.AI.MIT.EDU has been removed;
BUG-LISPM@AI.AI.MIT.EDU has been added.]
∂08-Oct-88 0430 @MC.LCS.MIT.EDU:hal@murren.ai.mit.edu 1989 Conference on Lisp and History of Lisp -- Advance Notice
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Oct 88 04:29:51 PDT
Received: from murren.ai.mit.edu (TCP 2212600263) by MC.LCS.MIT.EDU 7 Oct 88 21:50:20 EDT
Received: by murren.ai.mit.edu (5.59/1.5)
id AA14603; Fri, 7 Oct 88 21:27:27 EDT
Date: Fri, 7 Oct 88 21:27:27 EDT
From: hal@murren.ai.mit.edu (Hal Abelson)
Message-Id: <8810080127.AA14603@murren.ai.mit.edu>
To: arpanet-bboard@mc.lcs.mit.edu, lisp-forum@mc.lcs.mit.edu,
scheme@mc.lcs.mit.edu
Subject: 1989 Conference on Lisp and History of Lisp -- Advance Notice
Reply-To: hal@zurich.ai.mit.edu
HAPPY 30TH BIRTHDAY FOR LISP CONFERENCE
In recognition of the 30th birthday of the Lisp programming language,
the ACM is sponsoring a special conference on Lisp and the history of
Lisp, to be held at MIT, November 28 through December 1 1989.
Part of the conference will deal with technical issues of current
interest to the Lisp community (similar to Lisp presentations at the
Lisp and Functional Programming conferences). There also be sessions
devoted to historical papers, evolution of Lisp implementation
technology, perspectives on the past and future of Lisp, and so on.
A formal call for abstracts (which will be due next May) will appear
in a few months.
In the meantime, we would like to solicit your advice about
appropriate special events for this conference. For example, people
have suggested presenting awards for "distinguished contributions to
Lisp." Are there particular panel discussions you would like to see?
Or other events you think would be appropriate for a birthday
celebration?
Please mail us your suggestions.
For the program committee:
Dick Gabriel
Guy Steele
Jan Zubkoff
Hal Abelson
send suggestions to
Hal Abelson
MIT
545 Technology Square
Cambridge, MA 02129
hal@zurich.ai.mit.edu